Skip to content
Snippets Groups Projects
  1. Apr 30, 2023
    • Greg Kroah-Hartman's avatar
    • Alexandre Ghiti's avatar
      riscv: No need to relocate the dtb as it lies in the fixmap region · b38092f3
      Alexandre Ghiti authored
      
      commit 1b50f956 upstream.
      
      We used to access the dtb via its linear mapping address but now that the
      dtb early mapping was moved in the fixmap region, we can keep using this
      address since it is present in swapper_pg_dir, and remove the dtb
      relocation.
      
      Note that the relocation was wrong anyway since early_memremap() is
      restricted to 256K whereas the maximum fdt size is 2MB.
      
      Signed-off-by: default avatarAlexandre Ghiti <alexghiti@rivosinc.com>
      Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Tested-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Link: https://lore.kernel.org/r/20230329081932.79831-4-alexghiti@rivosinc.com
      
      
      Cc: stable@vger.kernel.org # 6.2.x
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b38092f3
    • Alexandre Ghiti's avatar
      riscv: Do not set initial_boot_params to the linear address of the dtb · 7c1c28d1
      Alexandre Ghiti authored
      
      commit f1581626 upstream.
      
      early_init_dt_verify() is already called in parse_dtb() and since the dtb
      address does not change anymore (it is now in the fixmap region), no need
      to reset initial_boot_params by calling early_init_dt_verify() again.
      
      Signed-off-by: default avatarAlexandre Ghiti <alexghiti@rivosinc.com>
      Link: https://lore.kernel.org/r/20230329081932.79831-3-alexghiti@rivosinc.com
      
      
      Cc: stable@vger.kernel.org # 6.2.x
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c1c28d1
    • Alexandre Ghiti's avatar
      riscv: Move early dtb mapping into the fixmap region · cd692130
      Alexandre Ghiti authored
      
      commit ef69d255 upstream.
      
      riscv establishes 2 virtual mappings:
      
      - early_pg_dir maps the kernel which allows to discover the system
        memory
      - swapper_pg_dir installs the final mapping (linear mapping included)
      
      We used to map the dtb in early_pg_dir using DTB_EARLY_BASE_VA, and this
      mapping was not carried over in swapper_pg_dir. It happens that
      early_init_fdt_scan_reserved_mem() must be called before swapper_pg_dir is
      setup otherwise we could allocate reserved memory defined in the dtb.
      And this function initializes reserved_mem variable with addresses that
      lie in the early_pg_dir dtb mapping: when those addresses are reused
      with swapper_pg_dir, this mapping does not exist and then we trap.
      
      The previous "fix" was incorrect as early_init_fdt_scan_reserved_mem()
      must be called before swapper_pg_dir is set up otherwise we could
      allocate in reserved memory defined in the dtb.
      
      So move the dtb mapping in the fixmap region which is established in
      early_pg_dir and handed over to swapper_pg_dir.
      
      Fixes: 922b0375 ("riscv: Fix memblock reservation for device tree blob")
      Fixes: 8f3a2b4a ("RISC-V: Move DT mapping outof fixmap")
      Fixes: 50e63dd8 ("riscv: fix reserved memory setup")
      Reported-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Link: https://lore.kernel.org/all/f8e67f82-103d-156c-deb0-d6d6e2756f5e@microchip.com/
      
      
      Signed-off-by: default avatarAlexandre Ghiti <alexghiti@rivosinc.com>
      Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Tested-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Link: https://lore.kernel.org/r/20230329081932.79831-2-alexghiti@rivosinc.com
      
      
      Cc: stable@vger.kernel.org # 6.2.x
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd692130
    • Stephen Boyd's avatar
      driver core: Don't require dynamic_debug for initcall_debug probe timing · 085887a6
      Stephen Boyd authored
      
      commit e2f06aa8 upstream.
      
      Don't require the use of dynamic debug (or modification of the kernel to
      add a #define DEBUG to the top of this file) to get the printk message
      about driver probe timing. This printk is only emitted when
      initcall_debug is enabled on the kernel commandline, and it isn't
      immediately obvious that you have to do something else to debug boot
      timing issues related to driver probe. Add a comment too so it doesn't
      get converted back to pr_debug().
      
      Fixes: eb7fbc9f ("driver core: Add missing '\n' in log messages")
      Cc: stable <stable@kernel.org>
      Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
      Cc: Brian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Link: https://lore.kernel.org/r/20230412225842.3196599-1-swboyd@chromium.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      085887a6
    • Arınç ÜNAL's avatar
      USB: serial: option: add UNISOC vendor and TOZED LT70C product · 99a5dea7
      Arınç ÜNAL authored
      
      commit a095edfc upstream.
      
      Add UNISOC vendor ID and TOZED LT70-C modem which is based from UNISOC
      SL8563. The modem supports the NCM mode. Interface 0 is used for running
      the AT commands. Interface 12 is the ADB interface.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1782 ProdID=4055 Rev=04.04
      S:  Manufacturer=Unisoc Phone
      S:  Product=Unisoc Phone
      S:  SerialNumber=<redacted>
      C:  #Ifs=14 Cfg#= 1 Atr=c0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
      E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#=10 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#=11 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#=12 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
      E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#=13 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
      E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
      I:  If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
      E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
      I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
      E:  Ad=88(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
      I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      
      Signed-off-by: default avatarArınç ÜNAL <arinc.unal@arinc9.com>
      Link: https://lore.kernel.org/r/20230417152003.243248-1-arinc.unal@arinc9.com
      
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99a5dea7
    • Genjian Zhang's avatar
      btrfs: fix uninitialized variable warnings · cfa90d22
      Genjian Zhang authored
      
      commit 8ba7d5f5 upstream.
      
      There are some warnings on older compilers (gcc 10, 7) or non-x86_64
      architectures (aarch64).  As btrfs wants to enable -Wmaybe-uninitialized
      by default, fix the warnings even though it's not necessary on recent
      compilers (gcc 12+).
      
      ../fs/btrfs/volumes.c: In function ‘btrfs_init_new_device’:
      ../fs/btrfs/volumes.c:2703:3: error: ‘seed_devices’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       2703 |   btrfs_setup_sprout(fs_info, seed_devices);
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      ../fs/btrfs/send.c: In function ‘get_cur_inode_state’:
      ../include/linux/compiler.h:70:32: error: ‘right_gen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         70 |   (__if_trace.miss_hit[1]++,1) :  \
            |                                ^
      ../fs/btrfs/send.c:1878:6: note: ‘right_gen’ was declared here
       1878 |  u64 right_gen;
            |      ^~~~~~~~~
      
      Reported-by: default avatark2ci <kernel-bot@kylinos.cn>
      Signed-off-by: default avatarGenjian Zhang <zhanggenjian@kylinos.cn>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ update changelog ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfa90d22
    • Marek Vasut's avatar
      wifi: brcmfmac: add Cypress 43439 SDIO ids · 65c77860
      Marek Vasut authored
      
      commit cc4cffc3 upstream.
      
      Add SDIO ids for use with the muRata 1YN (Cypress CYW43439).
      The odd thing about this is that the previous 1YN populated
      on M.2 card for evaluation purposes had BRCM SDIO vendor ID,
      while the chip populated on real hardware has a Cypress one.
      The device ID also differs between the two devices. But they
      are both 43439 otherwise, so add the IDs for both.
      
      On-device 1YN (43439), the new one, chip label reads "1YN":
      ```
      /sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device
      0x04b4
      0xbd3d
      ```
      
      EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4":
      ```
      /sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device
      0x02d0
      0xa9a6
      ```
      
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65c77860
    • Ruihan Li's avatar
      bluetooth: Perform careful capability checks in hci_sock_ioctl() · 727b3ea8
      Ruihan Li authored
      
      commit 25c150ac upstream.
      
      Previously, capability was checked using capable(), which verified that the
      caller of the ioctl system call had the required capability. In addition,
      the result of the check would be stored in the HCI_SOCK_TRUSTED flag,
      making it persistent for the socket.
      
      However, malicious programs can abuse this approach by deliberately sharing
      an HCI socket with a privileged task. The HCI socket will be marked as
      trusted when the privileged task occasionally makes an ioctl call.
      
      This problem can be solved by using sk_capable() to check capability, which
      ensures that not only the current task but also the socket opener has the
      specified capability, thus reducing the risk of privilege escalation
      through the previously identified vulnerability.
      
      Cc: stable@vger.kernel.org
      Fixes: f81f5b2d ("Bluetooth: Send control open and close messages for HCI raw sockets")
      Signed-off-by: default avatarRuihan Li <lrh2000@pku.edu.cn>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      727b3ea8
    • Werner Sembach's avatar
      gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU · 838969b9
      Werner Sembach authored
      
      commit 782eea0c upstream.
      
      commit 1796f808 ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
      changed the policy such that I2C touchpads may be able to wake up the
      system by default if the system is configured as such.
      
      However on Clevo NL5xNU there is a mistake in the ACPI tables that the
      TP_ATTN# signal connected to GPIO 9 is configured as ActiveLow and level
      triggered but connected to a pull up. As soon as the system suspends the
      touchpad loses power and then the system wakes up.
      
      To avoid this problem, introduce a quirk for this model that will prevent
      the wakeup capability for being set for GPIO 9.
      
      This patch is analoge to a very similar patch for NL5xRU, just the DMI
      string changed.
      
      Signed-off-by: default avatarWerner Sembach <wse@tuxedocomputers.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      838969b9
    • Daniel Vetter's avatar
      drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var · 7a362310
      Daniel Vetter authored
      
      commit 1935f0de upstream.
      
      Drivers are supposed to fix this up if needed if they don't outright
      reject it. Uncovered by 6c11df58 ("fbmem: Check virtual screen
      sizes in fb_set_var()").
      
      Reported-by: default avatar <syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com>
      Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc
      
      
      Cc: stable@vger.kernel.org # v5.4+
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Javier Martinez Canillas <javierm@redhat.com>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-1-daniel.vetter@ffwll.ch
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a362310
    • Jisoo Jang's avatar
      wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() · 22818662
      Jisoo Jang authored
      
      commit 0da40e01 upstream.
      
      Fix a slab-out-of-bounds read that occurs in kmemdup() called from
      brcmf_get_assoc_ies().
      The bug could occur when assoc_info->req_len, data from a URB provided
      by a USB device, is bigger than the size of buffer which is defined as
      WL_EXTRA_BUF_MAX.
      
      Add the size check for req_len/resp_len of assoc_info.
      
      Found by a modified version of syzkaller.
      
      [   46.592467][    T7] ==================================================================
      [   46.594687][    T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
      [   46.596572][    T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
      [   46.598575][    T7]
      [   46.599157][    T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G           O      5.14.0+ #145
      [   46.601333][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [   46.604360][    T7] Workqueue: events brcmf_fweh_event_worker
      [   46.605943][    T7] Call Trace:
      [   46.606584][    T7]  dump_stack_lvl+0x8e/0xd1
      [   46.607446][    T7]  print_address_description.constprop.0.cold+0x93/0x334
      [   46.608610][    T7]  ? kmemdup+0x3e/0x50
      [   46.609341][    T7]  kasan_report.cold+0x79/0xd5
      [   46.610151][    T7]  ? kmemdup+0x3e/0x50
      [   46.610796][    T7]  kasan_check_range+0x14e/0x1b0
      [   46.611691][    T7]  memcpy+0x20/0x60
      [   46.612323][    T7]  kmemdup+0x3e/0x50
      [   46.612987][    T7]  brcmf_get_assoc_ies+0x967/0xf60
      [   46.613904][    T7]  ? brcmf_notify_vif_event+0x3d0/0x3d0
      [   46.614831][    T7]  ? lock_chain_count+0x20/0x20
      [   46.615683][    T7]  ? mark_lock.part.0+0xfc/0x2770
      [   46.616552][    T7]  ? lock_chain_count+0x20/0x20
      [   46.617409][    T7]  ? mark_lock.part.0+0xfc/0x2770
      [   46.618244][    T7]  ? lock_chain_count+0x20/0x20
      [   46.619024][    T7]  brcmf_bss_connect_done.constprop.0+0x241/0x2e0
      [   46.620019][    T7]  ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
      [   46.620818][    T7]  ? __lock_acquire+0x181f/0x5790
      [   46.621462][    T7]  brcmf_notify_connect_status+0x448/0x1950
      [   46.622134][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
      [   46.622736][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
      [   46.623390][    T7]  ? find_held_lock+0x2d/0x110
      [   46.623962][    T7]  ? brcmf_fweh_event_worker+0x19f/0xc60
      [   46.624603][    T7]  ? mark_held_locks+0x9f/0xe0
      [   46.625145][    T7]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
      [   46.625871][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
      [   46.626545][    T7]  brcmf_fweh_call_event_handler.isra.0+0x90/0x100
      [   46.627338][    T7]  brcmf_fweh_event_worker+0x557/0xc60
      [   46.627962][    T7]  ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
      [   46.628736][    T7]  ? rcu_read_lock_sched_held+0xa1/0xd0
      [   46.629396][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
      [   46.629970][    T7]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
      [   46.630649][    T7]  process_one_work+0x92b/0x1460
      [   46.631205][    T7]  ? pwq_dec_nr_in_flight+0x330/0x330
      [   46.631821][    T7]  ? rwlock_bug.part.0+0x90/0x90
      [   46.632347][    T7]  worker_thread+0x95/0xe00
      [   46.632832][    T7]  ? __kthread_parkme+0x115/0x1e0
      [   46.633393][    T7]  ? process_one_work+0x1460/0x1460
      [   46.633957][    T7]  kthread+0x3a1/0x480
      [   46.634369][    T7]  ? set_kthread_struct+0x120/0x120
      [   46.634933][    T7]  ret_from_fork+0x1f/0x30
      [   46.635431][    T7]
      [   46.635687][    T7] Allocated by task 7:
      [   46.636151][    T7]  kasan_save_stack+0x1b/0x40
      [   46.636628][    T7]  __kasan_kmalloc+0x7c/0x90
      [   46.637108][    T7]  kmem_cache_alloc_trace+0x19e/0x330
      [   46.637696][    T7]  brcmf_cfg80211_attach+0x4a0/0x4040
      [   46.638275][    T7]  brcmf_attach+0x389/0xd40
      [   46.638739][    T7]  brcmf_usb_probe+0x12de/0x1690
      [   46.639279][    T7]  usb_probe_interface+0x2aa/0x760
      [   46.639820][    T7]  really_probe+0x205/0xb70
      [   46.640342][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.640876][    T7]  driver_probe_device+0x4e/0x150
      [   46.641445][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.642000][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.642543][    T7]  __device_attach+0x23f/0x3a0
      [   46.643065][    T7]  bus_probe_device+0x1da/0x290
      [   46.643644][    T7]  device_add+0xb7b/0x1eb0
      [   46.644130][    T7]  usb_set_configuration+0xf59/0x16f0
      [   46.644720][    T7]  usb_generic_driver_probe+0x82/0xa0
      [   46.645295][    T7]  usb_probe_device+0xbb/0x250
      [   46.645786][    T7]  really_probe+0x205/0xb70
      [   46.646258][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.646804][    T7]  driver_probe_device+0x4e/0x150
      [   46.647387][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.647926][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.648454][    T7]  __device_attach+0x23f/0x3a0
      [   46.648939][    T7]  bus_probe_device+0x1da/0x290
      [   46.649478][    T7]  device_add+0xb7b/0x1eb0
      [   46.649936][    T7]  usb_new_device.cold+0x49c/0x1029
      [   46.650526][    T7]  hub_event+0x1c98/0x3950
      [   46.650975][    T7]  process_one_work+0x92b/0x1460
      [   46.651535][    T7]  worker_thread+0x95/0xe00
      [   46.651991][    T7]  kthread+0x3a1/0x480
      [   46.652413][    T7]  ret_from_fork+0x1f/0x30
      [   46.652885][    T7]
      [   46.653131][    T7] The buggy address belongs to the object at ffff888019442000
      [   46.653131][    T7]  which belongs to the cache kmalloc-2k of size 2048
      [   46.654669][    T7] The buggy address is located 0 bytes inside of
      [   46.654669][    T7]  2048-byte region [ffff888019442000, ffff888019442800)
      [   46.656137][    T7] The buggy address belongs to the page:
      [   46.656720][    T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440
      [   46.657792][    T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0
      [   46.658673][    T7] flags: 0x100000000010200(slab|head|node=0|zone=1)
      [   46.659422][    T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000
      [   46.660363][    T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
      [   46.661236][    T7] page dumped because: kasan: bad access detected
      [   46.661956][    T7] page_owner tracks the page as allocated
      [   46.662588][    T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0
      [   46.664271][    T7]  prep_new_page+0x1aa/0x240
      [   46.664763][    T7]  get_page_from_freelist+0x159a/0x27c0
      [   46.665340][    T7]  __alloc_pages+0x2da/0x6a0
      [   46.665847][    T7]  alloc_pages+0xec/0x1e0
      [   46.666308][    T7]  allocate_slab+0x380/0x4e0
      [   46.666770][    T7]  ___slab_alloc+0x5bc/0x940
      [   46.667264][    T7]  __slab_alloc+0x6d/0x80
      [   46.667712][    T7]  kmem_cache_alloc_trace+0x30a/0x330
      [   46.668299][    T7]  brcmf_usbdev_qinit.constprop.0+0x50/0x470
      [   46.668885][    T7]  brcmf_usb_probe+0xc97/0x1690
      [   46.669438][    T7]  usb_probe_interface+0x2aa/0x760
      [   46.669988][    T7]  really_probe+0x205/0xb70
      [   46.670487][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.671031][    T7]  driver_probe_device+0x4e/0x150
      [   46.671604][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.672192][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.672739][    T7] page_owner free stack trace missing
      [   46.673335][    T7]
      [   46.673620][    T7] Memory state around the buggy address:
      [   46.674213][    T7]  ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   46.675083][    T7]  ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   46.675994][    T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.676875][    T7]                    ^
      [   46.677323][    T7]  ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.678190][    T7]  ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.679052][    T7] ==================================================================
      [   46.679945][    T7] Disabling lock debugging due to kernel taint
      [   46.680725][    T7] Kernel panic - not syncing:
      
      Reviewed-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarJisoo Jang <jisoo.jang@yonsei.ac.kr>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22818662
    • Liam R. Howlett's avatar
      mm/mempolicy: fix use-after-free of VMA iterator · 0078cd17
      Liam R. Howlett authored
      commit f4e9e0e6 upstream.
      
      set_mempolicy_home_node() iterates over a list of VMAs and calls
      mbind_range() on each VMA, which also iterates over the singular list of
      the VMA passed in and potentially splits the VMA.  Since the VMA iterator
      is not passed through, set_mempolicy_home_node() may now point to a stale
      node in the VMA tree.  This can result in a UAF as reported by syzbot.
      
      Avoid the stale maple tree node by passing the VMA iterator through to the
      underlying call to split_vma().
      
      mbind_range() is also overly complicated, since there are two calling
      functions and one already handles iterating over the VMAs.  Simplify
      mbind_range() to only handle merging and splitting of the VMAs.
      
      Align the new loop in do_mbind() and existing loop in
      set_mempolicy_home_node() to use the reduced mbind_range() function.  This
      allows for a single location of the range calculation and avoids
      constantly looking up the previous VMA (since this is a loop over the
      VMAs).
      
      Link: https://lore.kernel.org/linux-mm/000000000000c93feb05f87e24ad@google.com/
      
      
      Fixes: 66850be5 ("mm/mempolicy: use vma iterator & maple state instead of vma linked list")
      Signed-off-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Reported-by: default avatar <syzbot+a7c1ec5b1d71ceaa5186@syzkaller.appspotmail.com>
        Link: https://lkml.kernel.org/r/20230410152205.2294819-1-Liam.Howlett@oracle.com
      
      
      Tested-by: default avatar <syzbot+a7c1ec5b1d71ceaa5186@syzkaller.appspotmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0078cd17
    • Ziwei Dai's avatar
      rcu/kvfree: Avoid freeing new kfree_rcu() memory after old grace period · 37e4beb6
      Ziwei Dai authored
      
      commit 5da7cb19 upstream.
      
      Memory passed to kvfree_rcu() that is to be freed is tracked by a
      per-CPU kfree_rcu_cpu structure, which in turn contains pointers
      to kvfree_rcu_bulk_data structures that contain pointers to memory
      that has not yet been handed to RCU, along with an kfree_rcu_cpu_work
      structure that tracks the memory that has already been handed to RCU.
      These structures track three categories of memory: (1) Memory for
      kfree(), (2) Memory for kvfree(), and (3) Memory for both that arrived
      during an OOM episode.  The first two categories are tracked in a
      cache-friendly manner involving a dynamically allocated page of pointers
      (the aforementioned kvfree_rcu_bulk_data structures), while the third
      uses a simple (but decidedly cache-unfriendly) linked list through the
      rcu_head structures in each block of memory.
      
      On a given CPU, these three categories are handled as a unit, with that
      CPU's kfree_rcu_cpu_work structure having one pointer for each of the
      three categories.  Clearly, new memory for a given category cannot be
      placed in the corresponding kfree_rcu_cpu_work structure until any old
      memory has had its grace period elapse and thus has been removed.  And
      the kfree_rcu_monitor() function does in fact check for this.
      
      Except that the kfree_rcu_monitor() function checks these pointers one
      at a time.  This means that if the previous kfree_rcu() memory passed
      to RCU had only category 1 and the current one has only category 2, the
      kfree_rcu_monitor() function will send that current category-2 memory
      along immediately.  This can result in memory being freed too soon,
      that is, out from under unsuspecting RCU readers.
      
      To see this, consider the following sequence of events, in which:
      
      o	Task A on CPU 0 calls rcu_read_lock(), then uses "from_cset",
      	then is preempted.
      
      o	CPU 1 calls kfree_rcu(cset, rcu_head) in order to free "from_cset"
      	after a later grace period.  Except that "from_cset" is freed
      	right after the previous grace period ended, so that "from_cset"
      	is immediately freed.  Task A resumes and references "from_cset"'s
      	member, after which nothing good happens.
      
      In full detail:
      
      CPU 0					CPU 1
      ----------------------			----------------------
      count_memcg_event_mm()
      |rcu_read_lock()  <---
      |mem_cgroup_from_task()
       |// css_set_ptr is the "from_cset" mentioned on CPU 1
       |css_set_ptr = rcu_dereference((task)->cgroups)
       |// Hard irq comes, current task is scheduled out.
      
      					cgroup_attach_task()
      					|cgroup_migrate()
      					|cgroup_migrate_execute()
      					|css_set_move_task(task, from_cset, to_cset, true)
      					|cgroup_move_task(task, to_cset)
      					|rcu_assign_pointer(.., to_cset)
      					|...
      					|cgroup_migrate_finish()
      					|put_css_set_locked(from_cset)
      					|from_cset->refcount return 0
      					|kfree_rcu(cset, rcu_head) // free from_cset after new gp
      					|add_ptr_to_bulk_krc_lock()
      					|schedule_delayed_work(&krcp->monitor_work, ..)
      
      					kfree_rcu_monitor()
      					|krcp->bulk_head[0]'s work attached to krwp->bulk_head_free[]
      					|queue_rcu_work(system_wq, &krwp->rcu_work)
      					|if rwork->rcu.work is not in WORK_STRUCT_PENDING_BIT state,
      					|call_rcu(&rwork->rcu, rcu_work_rcufn) <--- request new gp
      
      					// There is a perious call_rcu(.., rcu_work_rcufn)
      					// gp end, rcu_work_rcufn() is called.
      					rcu_work_rcufn()
      					|__queue_work(.., rwork->wq, &rwork->work);
      
      					|kfree_rcu_work()
      					|krwp->bulk_head_free[0] bulk is freed before new gp end!!!
      					|The "from_cset" is freed before new gp end.
      
      // the task resumes some time later.
       |css_set_ptr->subsys[(subsys_id) <--- Caused kernel crash, because css_set_ptr is freed.
      
      This commit therefore causes kfree_rcu_monitor() to refrain from moving
      kfree_rcu() memory to the kfree_rcu_cpu_work structure until the RCU
      grace period has completed for all three categories.
      
      v2: Use helper function instead of inserted code block at kfree_rcu_monitor().
      
      Fixes: 34c88174 ("rcu: Support kfree_bulk() interface in kfree_rcu()")
      Fixes: 5f3c8d62 ("rcu/tree: Maintain separate array for vmalloc ptrs")
      Reported-by: default avatarMukesh Ojha <quic_mojha@quicinc.com>
      Signed-off-by: default avatarZiwei Dai <ziwei.dai@unisoc.com>
      Reviewed-by: default avatarUladzislau Rezki (Sony) <urezki@gmail.com>
      Tested-by: default avatarUladzislau Rezki (Sony) <urezki@gmail.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@kernel.org>
      Signed-off-by: default avatarUladzislau Rezki (Sony) <urezki@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37e4beb6
    • David Gow's avatar
      um: Only disable SSE on clang to work around old GCC bugs · 4b09ccd2
      David Gow authored
      commit a3046a61 upstream.
      
      As part of the Rust support for UML, we disable SSE (and similar flags)
      to match the normal x86 builds. This both makes sense (we ideally want a
      similar configuration to x86), and works around a crash bug with SSE
      generation under Rust with LLVM.
      
      However, this breaks compiling stdlib.h under gcc < 11, as the x86_64
      ABI requires floating-point return values be stored in an SSE register.
      gcc 11 fixes this by only doing register allocation when a function is
      actually used, and since we never use atof(), it shouldn't be a problem:
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99652
      
      
      
      Nevertheless, only disable SSE on clang setups, as that's a simple way
      of working around everyone's bugs.
      
      Fixes: 88498186 ("rust: arch/um: Disable FP/SIMD instruction to match x86")
      Reported-by: default avatarRoberto Sassu <roberto.sassu@huaweicloud.com>
      Link: https://lore.kernel.org/linux-um/6df2ecef9011d85654a82acd607fdcbc93ad593c.camel@huaweicloud.com/
      
      
      Tested-by: default avatarRoberto Sassu <roberto.sassu@huaweicloud.com>
      Tested-by: default avatarSeongJae Park <sj@kernel.org>
      Signed-off-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarVincenzo Palazzo <vincenzopalazzodev@gmail.com>
      Tested-by: default avatarArthur Grillo <arthurgrillo@riseup.net>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b09ccd2
    • David Gow's avatar
      rust: arch/um: Disable FP/SIMD instruction to match x86 · 3d707c0e
      David Gow authored
      commit 88498186 upstream.
      
      The kernel disables all SSE and similar FP/SIMD instructions on
      x86-based architectures (partly because we shouldn't be using floats in
      the kernel, and partly to avoid the need for stack alignment, see:
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 )
      
      UML does not do the same thing, which isn't in itself a problem, but
      does add to the list of differences between UML and "normal" x86 builds.
      
      In addition, there was a crash bug with LLVM < 15 / rustc < 1.65 when
      building with SSE, so disabling it fixes rust builds with earlier
      compiler versions, see:
      https://github.com/Rust-for-Linux/linux/pull/881
      
      
      
      Signed-off-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarSergio González Collado <sergio.collado@gmail.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d707c0e
  2. Apr 26, 2023
Loading