Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg<br /> <br /> syzbot reported the following uninit-value access issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x21c/0x280 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737<br /> usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032<br /> usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241<br /> usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554<br /> hub_port_connect drivers/usb/core/hub.c:5208 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]<br /> port_event drivers/usb/core/hub.c:5494 [inline]<br /> hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576<br /> process_one_work+0x1688/0x2140 kernel/workqueue.c:2269<br /> worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415<br /> kthread+0x551/0x590 kernel/kthread.c:292<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293<br /> <br /> Local variable ----buf.i87@smsc75xx_bind created at:<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> <br /> This issue is caused because usbnet_read_cmd() reads less bytes than requested<br /> (zero byte in the reproducer). In this case, &amp;#39;buf&amp;#39; is not properly filled.<br /> <br /> This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads<br /> less bytes than requested.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: sony: Fix a potential memory leak in sony_probe()<br /> <br /> If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()<br /> should be called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: Fix a memory corruption issue<br /> <br /> A few lines above, space is kzalloc()&amp;#39;ed for:<br /> sizeof(struct iwl_nvm_data) +<br /> sizeof(struct ieee80211_channel) +<br /> sizeof(struct ieee80211_rate)<br /> <br /> &amp;#39;mvm-&gt;nvm_data&amp;#39; is a &amp;#39;struct iwl_nvm_data&amp;#39;, so it is fine.<br /> <br /> At the end of this structure, there is the &amp;#39;channels&amp;#39; flex array.<br /> Each element is of type &amp;#39;struct ieee80211_channel&amp;#39;.<br /> So only 1 element is allocated in this array.<br /> <br /> When doing:<br /> mvm-&gt;nvm_data-&gt;bands[0].channels = mvm-&gt;nvm_data-&gt;channels;<br /> We point at the first element of the &amp;#39;channels&amp;#39; flex array.<br /> So this is fine.<br /> <br /> However, when doing:<br /> mvm-&gt;nvm_data-&gt;bands[0].bitrates =<br /> (void *)((u8 *)mvm-&gt;nvm_data-&gt;channels + 1);<br /> because of the "(u8 *)" cast, we add only 1 to the address of the beginning<br /> of the flex array.<br /> <br /> It is likely that we want point at the &amp;#39;struct ieee80211_rate&amp;#39; allocated<br /> just after.<br /> <br /> Remove the spurious casting so that the pointer arithmetic works as<br /> expected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix TX CQE error handling<br /> <br /> For an unknown TX CQE error type (probably from a newer hardware),<br /> still free the SKB, update the queue tail, etc., otherwise the<br /> accounting will be wrong.<br /> <br /> Also, TX errors can be triggered by injecting corrupted packets, so<br /> replace the WARN_ONCE to ratelimited error logging.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Avoid memory allocation in iommu_suspend()<br /> <br /> The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.<br /> Allocating memory with the GFP_KERNEL flag may re-enable IRQs during<br /> the suspend callback, which can cause intermittent suspend/hibernation<br /> problems with the following kernel traces:<br /> <br /> Calling iommu_suspend+0x0/0x1d0<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0<br /> ...<br /> CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1<br /> RIP: 0010:ktime_get+0x9b/0xb0<br /> ...<br /> Call Trace:<br /> <br /> tick_sched_timer+0x22/0x90<br /> ? __pfx_tick_sched_timer+0x10/0x10<br /> __hrtimer_run_queues+0x111/0x2b0<br /> hrtimer_interrupt+0xfa/0x230<br /> __sysvec_apic_timer_interrupt+0x63/0x140<br /> sysvec_apic_timer_interrupt+0x7b/0xa0<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1f/0x30<br /> ...<br /> ------------[ cut here ]------------<br /> Interrupts enabled after iommu_suspend+0x0/0x1d0<br /> WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270<br /> CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1<br /> RIP: 0010:syscore_suspend+0x147/0x270<br /> ...<br /> Call Trace:<br /> <br /> hibernation_snapshot+0x25b/0x670<br /> hibernate+0xcd/0x390<br /> state_store+0xcf/0xe0<br /> kobj_attr_store+0x13/0x30<br /> sysfs_kf_write+0x3f/0x50<br /> kernfs_fop_write_iter+0x128/0x200<br /> vfs_write+0x1fd/0x3c0<br /> ksys_write+0x6f/0xf0<br /> __x64_sys_write+0x1d/0x30<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Given that only 4 words memory is needed, avoid the memory allocation in<br /> iommu_suspend().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()<br /> <br /> When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y<br /> and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.<br /> <br /> Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary<br /> variables"), the damon_destroy_ctx() is removed, but still call<br /> damon_new_target() and damon_new_region(), the damon_region which is<br /> allocated by kmem_cache_alloc() in damon_new_region() and the damon_target<br /> which is allocated by kmalloc in damon_new_target() are not freed. And<br /> the damon_region which is allocated in damon_new_region() in<br /> damon_set_regions() is also not freed.<br /> <br /> So use damon_destroy_target to free all the damon_regions and damon_target.<br /> <br /> unreferenced object 0xffff888107c9a940 (size 64):<br /> comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk<br /> 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] damon_new_target+0x3f/0x1b0<br /> [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0<br /> [] damon_test_apply_three_regions1+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff8881079cc740 (size 56):<br /> comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)<br /> hex dump (first 32 bytes):<br /> 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................<br /> 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk<br /> backtrace:<br /> [] damon_new_region+0x22/0x1c0<br /> [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0<br /> [] damon_test_apply_three_regions1+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff888107c9ac40 (size 64):<br /> comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk<br /> a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] damon_new_target+0x3f/0x1b0<br /> [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0<br /> [] damon_test_apply_three_regions2+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff8881079ccc80 (size 56):<br /> comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)<br /> hex dump (first 32 bytes):<br /> 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................<br /> 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk<br /> backtrace:<br /> [] damon_new_region+0x22/0x1c0<br /> [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0<br /> [] damon_test_apply_three_regions2+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved<br /> <br /> Adding a reserved memory region for the framebuffer memory<br /> (the splash memory region set up by the bootloader).<br /> <br /> It fixes a kernel panic (arm-smmu: Unhandled context fault<br /> at this particular memory region) reported on DB845c running<br /> v5.10.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()<br /> <br /> After the commit in Fixes:, if a module that created a slab cache does not<br /> release all of its allocated objects before destroying the cache (at rmmod<br /> time), we might end up releasing the kmem_cache object without removing it<br /> from the slab_caches list thus corrupting the list as kmem_cache_destroy()<br /> ignores the return value from shutdown_cache(), which in turn never removes<br /> the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails<br /> to release all of the cache&amp;#39;s slabs.<br /> <br /> This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y<br /> as after that ill release the system will immediately trip on list_add,<br /> or list_del, assertions similar to the one shown below as soon as another<br /> kmem_cache gets created, or destroyed:<br /> <br /> [ 1041.213632] list_del corruption. next-&gt;prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268)<br /> [ 1041.219165] ------------[ cut here ]------------<br /> [ 1041.221517] kernel BUG at lib/list_debug.c:62!<br /> [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15<br /> [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023<br /> [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0<br /> <br /> Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y,<br /> is to set slub_debug to poison the released objects and then just run<br /> cat /proc/slabinfo after removing the module that leaks slab objects,<br /> in which case the kernel will panic:<br /> <br /> [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI<br /> [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15<br /> [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023<br /> [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0<br /> <br /> This patch fixes this issue by properly checking shutdown_cache()&amp;#39;s<br /> return value before taking the kmem_cache_release() branch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: fix memory leak on -&gt;hpd_notify callback<br /> <br /> The EDID returned by drm_bridge_get_edid() needs to be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"<br /> <br /> This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.<br /> <br /> The commit above is reverted as it did not solve the original issue.<br /> <br /> gsm_cleanup_mux() tries to free up the virtual ttys by calling<br /> gsm_dlci_release() for each available DLCI. There, dlci_put() is called to<br /> decrease the reference counter for the DLCI via tty_port_put() which<br /> finally calls gsm_dlci_free(). This already clears the pointer which is<br /> being checked in gsm_cleanup_mux() before calling gsm_dlci_release().<br /> Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux()<br /> as done in the reverted commit. The commit introduces a null pointer<br /> dereference:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x156/0x420<br /> ? search_exception_tables+0x37/0x50<br /> ? fixup_exception+0x21/0x310<br /> ? exc_page_fault+0x69/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? tty_port_put+0x19/0xa0<br /> gsmtty_cleanup+0x29/0x80 [n_gsm]<br /> release_one_tty+0x37/0xe0<br /> process_one_work+0x1e6/0x3e0<br /> worker_thread+0x4c/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe1/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The actual issue is that nothing guards dlci_put() from being called<br /> multiple times while the tty driver was triggered but did not yet finished<br /> calling gsm_dlci_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix OOB read<br /> <br /> If the index provided by the user is bigger than the mask size, we might do<br /> an out of bound read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix potential key use-after-free<br /> <br /> When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()<br /> but returns 0 due to KRACK protection (identical key reinstall),<br /> ieee80211_gtk_rekey_add() will still return a pointer into the<br /> key, in a potential use-after-free. This normally doesn&amp;#39;t happen<br /> since it&amp;#39;s only called by iwlwifi in case of WoWLAN rekey offload<br /> which has its own KRACK protection, but still better to fix, do<br /> that by returning an error code and converting that to success on<br /> the cfg80211 boundary only, leaving the error for bad callers of<br /> ieee80211_gtk_rekey_add().