Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netmem: prevent TX of unreadable skbs<br /> <br /> Currently on stable trees we have support for netmem/devmem RX but not<br /> TX. It is not safe to forward/redirect an RX unreadable netmem packet<br /> into the device&amp;#39;s TX path, as the device may call dma-mapping APIs on<br /> dma addrs that should not be passed to it.<br /> <br /> Fix this by preventing the xmit of unreadable skbs.<br /> <br /> Tested by configuring tc redirect:<br /> <br /> sudo tc qdisc add dev eth1 ingress<br /> sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \<br /> tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1<br /> <br /> Before, I see unreadable skbs in the driver&amp;#39;s TX path passed to dma<br /> mapping APIs.<br /> <br /> After, I don&amp;#39;t see unreadable skbs in the driver&amp;#39;s TX path passed to dma<br /> mapping APIs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: prevent connection release during oplock break notification<br /> <br /> ksmbd_work could be freed when after connection release.<br /> Increment r_count of ksmbd_conn to indicate that requests<br /> are not finished yet and to not release the connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Set hugetlb mmap base address aligned with pmd size<br /> <br /> With ltp test case "testcases/bin/hugefork02", there is a dmesg error<br /> report message such as:<br /> <br /> kernel BUG at mm/hugetlb.c:5550!<br /> Oops - BUG[#1]:<br /> CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940<br /> a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000<br /> a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000<br /> t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000<br /> t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001<br /> t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280<br /> s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10<br /> s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08<br /> ra: 9000000000485538 unmap_vmas+0x130/0x218<br /> ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)<br /> PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)<br /> Call Trace:<br /> [] __unmap_hugepage_range+0x6f4/0x7d0<br /> [] unmap_vmas+0x12c/0x218<br /> [] exit_mmap+0xe0/0x308<br /> [] mmput+0x74/0x180<br /> [] do_exit+0x294/0x898<br /> [] do_group_exit+0x30/0x98<br /> [] get_signal+0x83c/0x868<br /> [] arch_do_signal_or_restart+0x54/0xfa0<br /> [] irqentry_exit_to_user_mode+0xb8/0x138<br /> [] tlb_do_page_fault_1+0x114/0x1b4<br /> <br /> The problem is that base address allocated from hugetlbfs is not aligned<br /> with pmd size. Here add a checking for hugetlbfs and align base address<br /> with pmd size. After this patch the test case "testcases/bin/hugefork02"<br /> passes to run.<br /> <br /> This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach<br /> generic_get_unmapped_area{_topdown} to handle hugetlb mappings").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: cleanup mana struct after debugfs_remove()<br /> <br /> When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),<br /> mana_gd_suspend() and mana_gd_resume() are called. If during this<br /> mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs<br /> pointer does not get reinitialized and ends up pointing to older,<br /> cleaned-up dentry.<br /> Further in the hibernation path, as part of power_down(), mana_gd_shutdown()<br /> is triggered. This call, unaware of the failures in resume, tries to cleanup<br /> the already cleaned up mana_port_debugfs value and hits the following bug:<br /> <br /> [ 191.359296] mana 7870:00:00.0: Shutdown was called<br /> [ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> [ 191.360584] #PF: supervisor write access in kernel mode<br /> [ 191.361125] #PF: error_code(0x0002) - not-present page<br /> [ 191.361727] PGD 1080ea067 P4D 0<br /> [ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI<br /> [ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2<br /> [ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024<br /> [ 191.364124] RIP: 0010:down_write+0x19/0x50<br /> [ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d<br /> [ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246<br /> [ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000<br /> [ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098<br /> [ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001<br /> [ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000<br /> [ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020<br /> [ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000<br /> [ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0<br /> [ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 191.372906] Call Trace:<br /> [ 191.373262] <br /> [ 191.373621] ? show_regs+0x64/0x70<br /> [ 191.374040] ? __die+0x24/0x70<br /> [ 191.374468] ? page_fault_oops+0x290/0x5b0<br /> [ 191.374875] ? do_user_addr_fault+0x448/0x800<br /> [ 191.375357] ? exc_page_fault+0x7a/0x160<br /> [ 191.375971] ? asm_exc_page_fault+0x27/0x30<br /> [ 191.376416] ? down_write+0x19/0x50<br /> [ 191.376832] ? down_write+0x12/0x50<br /> [ 191.377232] simple_recursive_removal+0x4a/0x2a0<br /> [ 191.377679] ? __pfx_remove_one+0x10/0x10<br /> [ 191.378088] debugfs_remove+0x44/0x70<br /> [ 191.378530] mana_detach+0x17c/0x4f0<br /> [ 191.378950] ? __flush_work+0x1e2/0x3b0<br /> [ 191.379362] ? __cond_resched+0x1a/0x50<br /> [ 191.379787] mana_remove+0xf2/0x1a0<br /> [ 191.380193] mana_gd_shutdown+0x3b/0x70<br /> [ 191.380642] pci_device_shutdown+0x3a/0x80<br /> [ 191.381063] device_shutdown+0x13e/0x230<br /> [ 191.381480] kernel_power_off+0x35/0x80<br /> [ 191.381890] hibernate+0x3c6/0x470<br /> [ 191.382312] state_store+0xcb/0xd0<br /> [ 191.382734] kobj_attr_store+0x12/0x30<br /> [ 191.383211] sysfs_kf_write+0x3e/0x50<br /> [ 191.383640] kernfs_fop_write_iter+0x140/0x1d0<br /> [ 191.384106] vfs_write+0x271/0x440<br /> [ 191.384521] ksys_write+0x72/0xf0<br /> [ 191.384924] __x64_sys_write+0x19/0x20<br /> [ 191.385313] x64_sys_call+0x2b0/0x20b0<br /> [ 191.385736] do_syscall_64+0x79/0x150<br /> [ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240<br /> [ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0<br /> [ 191.387124] ? __pfx_lru_add+0x10/0x10<br /> [ 191.387515] ? queued_spin_unlock+0x9/0x10<br /> [ 191.387937] ? do_anonymous_page+0x33c/0xa00<br /> [ 191.388374] ? __handle_mm_fault+0xcf3/0x1210<br /> [ 191.388805] ? __count_memcg_events+0xbe/0x180<br /> [ 191.389235] ? handle_mm_fault+0xae/0x300<br /> [ 19<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock<br /> <br /> There are multiple places from where the recovery work gets scheduled<br /> asynchronously. Also, there are multiple places where the caller waits<br /> synchronously for the recovery to be completed. One such place is during<br /> the PM shutdown() callback.<br /> <br /> If the device is not alive during recovery_work, it will try to reset the<br /> device using pci_reset_function(). This function internally will take the<br /> device_lock() first before resetting the device. By this time, if the lock<br /> has already been acquired, then recovery_work will get stalled while<br /> waiting for the lock. And if the lock was already acquired by the caller<br /> which waits for the recovery_work to be completed, it will lead to<br /> deadlock.<br /> <br /> This is what happened on the X1E80100 CRD device when the device died<br /> before shutdown() callback. Driver core calls the driver&amp;#39;s shutdown()<br /> callback while holding the device_lock() leading to deadlock.<br /> <br /> And this deadlock scenario can occur on other paths as well, like during<br /> the PM suspend() callback, where the driver core would hold the<br /> device_lock() before calling driver&amp;#39;s suspend() callback. And if the<br /> recovery_work was already started, it could lead to deadlock. This is also<br /> observed on the X1E80100 CRD.<br /> <br /> So to fix both issues, use pci_try_reset_function() in recovery_work. This<br /> function first checks for the availability of the device_lock() before<br /> trying to reset the device. If the lock is available, it will acquire it<br /> and reset the device. Otherwise, it will return -EAGAIN. If that happens,<br /> recovery_work will fail with the error message "Recovery failed" as not<br /> much could be done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Assign normalized_pix_clk when color depth = 14<br /> <br /> [WHY &amp; HOW]<br /> A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397<br /> calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the<br /> display_color_depth == COLOR_DEPTH_141414 is not handled. This is<br /> observed in Radeon RX 6600 XT.<br /> <br /> It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.<br /> <br /> Also fixes the indentation in get_norm_pix_clk.<br /> <br /> (cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla1280: Fix kernel oops when debug level &gt; 2<br /> <br /> A null dereference or oops exception will eventually occur when qla1280.c<br /> driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level &gt; 2. I<br /> think its clear from the code that the intention here is sg_dma_len(s) not<br /> length of sg_next(s) when printing the debug info.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl<br /> <br /> In the "pmcmd_ioctl" function, three memory objects allocated by<br /> kmalloc are initialized by "hcall_get_cpu_state", which are then<br /> copied to user space. The initializer is indeed implemented in<br /> "acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of<br /> information leakage due to uninitialized bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix extent range end unlock in cow_file_range()<br /> <br /> Running generic/751 on the for-next branch often results in a hang like<br /> below. They are both stack by locking an extent. This suggests someone<br /> forget to unlock an extent.<br /> <br /> INFO: task kworker/u128:1:12 blocked for more than 323 seconds.<br /> Not tainted 6.13.0-BTRFS-ZNS+ #503<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000<br /> Workqueue: btrfs-fixup btrfs_work_helper [btrfs]<br /> Call Trace:<br /> <br /> __schedule+0x534/0xdd0<br /> schedule+0x39/0x140<br /> __lock_extent+0x31b/0x380 [btrfs]<br /> ? __pfx_autoremove_wake_function+0x10/0x10<br /> btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]<br /> btrfs_work_helper+0xff/0x480 [btrfs]<br /> ? lock_release+0x178/0x2c0<br /> process_one_work+0x1ee/0x570<br /> ? srso_return_thunk+0x5/0x5f<br /> worker_thread+0x1d1/0x3b0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10b/0x230<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> INFO: task kworker/u134:0:184 blocked for more than 323 seconds.<br /> Not tainted 6.13.0-BTRFS-ZNS+ #503<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000<br /> Workqueue: writeback wb_workfn (flush-btrfs-4)<br /> Call Trace:<br /> <br /> __schedule+0x534/0xdd0<br /> schedule+0x39/0x140<br /> __lock_extent+0x31b/0x380 [btrfs]<br /> ? __pfx_autoremove_wake_function+0x10/0x10<br /> find_lock_delalloc_range+0xdb/0x260 [btrfs]<br /> writepage_delalloc+0x12f/0x500 [btrfs]<br /> ? srso_return_thunk+0x5/0x5f<br /> extent_write_cache_pages+0x232/0x840 [btrfs]<br /> btrfs_writepages+0x72/0x130 [btrfs]<br /> do_writepages+0xe7/0x260<br /> ? srso_return_thunk+0x5/0x5f<br /> ? lock_acquire+0xd2/0x300<br /> ? srso_return_thunk+0x5/0x5f<br /> ? find_held_lock+0x2b/0x80<br /> ? wbc_attach_and_unlock_inode.part.0+0x102/0x250<br /> ? wbc_attach_and_unlock_inode.part.0+0x102/0x250<br /> __writeback_single_inode+0x5c/0x4b0<br /> writeback_sb_inodes+0x22d/0x550<br /> __writeback_inodes_wb+0x4c/0xe0<br /> wb_writeback+0x2f6/0x3f0<br /> wb_workfn+0x32a/0x510<br /> process_one_work+0x1ee/0x570<br /> ? srso_return_thunk+0x5/0x5f<br /> worker_thread+0x1d1/0x3b0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10b/0x230<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> This happens because we have another success path for the zoned mode. When<br /> there is no active zone available, btrfs_reserve_extent() returns<br /> -EAGAIN. In this case, we have two reactions.<br /> <br /> (1) If the given range is never allocated, we can only wait for someone<br /> to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry<br /> afterward.<br /> <br /> (2) Or, if some allocations are already done, we must bail out and let<br /> the caller to send IOs for the allocation. This is because these IOs<br /> may be necessary to finish a zone.<br /> <br /> The commit 06f364284794 ("btrfs: do proper folio cleanup when<br /> cow_file_range() failed") moved the unlock code from the inside of the<br /> loop to the outside. So, previously, the allocated extents are unlocked<br /> just after the allocation and so before returning from the function.<br /> However, they are no longer unlocked on the case (2) above. That caused<br /> the hang issue.<br /> <br /> Fix the issue by modifying the &amp;#39;end&amp;#39; to the end of the allocated<br /> range. Then, we can exit the loop and the same unlock code can properly<br /> handle the case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: aggregator: protect driver attr handlers against module unload<br /> <br /> Both new_device_store and delete_device_store touch module global<br /> resources (e.g. gpio_aggregator_lock). To prevent race conditions with<br /> module unload, a reference needs to be held.<br /> <br /> Add try_module_get() in these handlers.<br /> <br /> For new_device_store, this eliminates what appears to be the most dangerous<br /> scenario: if an id is allocated from gpio_aggregator_idr but<br /> platform_device_register has not yet been called or completed, a concurrent<br /> module unload could fail to unregister/delete the device, leaving behind a<br /> dangling platform device/GPIO forwarder. This can result in various issues.<br /> The following simple reproducer demonstrates these problems:<br /> <br /> #!/bin/bash<br /> while :; do<br /> # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.<br /> echo &amp;#39;gpiochip0 0&amp;#39; &gt; /sys/bus/platform/drivers/gpio-aggregator/new_device<br /> done &amp;<br /> while :; do<br /> modprobe gpio-aggregator<br /> modprobe -r gpio-aggregator<br /> done &amp;<br /> wait<br /> <br /> Starting with the following warning, several kinds of warnings will appear<br /> and the system may become unstable:<br /> <br /> ------------[ cut here ]------------<br /> list_del corruption, ffff888103e2e980-&gt;next is LIST_POISON1 (dead000000000100)<br /> WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120<br /> [...]<br /> RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120<br /> [...]<br /> Call Trace:<br /> <br /> ? __list_del_entry_valid_or_report+0xa3/0x120<br /> ? __warn.cold+0x93/0xf2<br /> ? __list_del_entry_valid_or_report+0xa3/0x120<br /> ? report_bug+0xe6/0x170<br /> ? __irq_work_queue_local+0x39/0xe0<br /> ? handle_bug+0x58/0x90<br /> ? exc_invalid_op+0x13/0x60<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __list_del_entry_valid_or_report+0xa3/0x120<br /> gpiod_remove_lookup_table+0x22/0x60<br /> new_device_store+0x315/0x350 [gpio_aggregator]<br /> kernfs_fop_write_iter+0x137/0x1f0<br /> vfs_write+0x262/0x430<br /> ksys_write+0x60/0xd0<br /> do_syscall_64+0x6c/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix bug on trap in smb2_lock<br /> <br /> If lock count is greater than 1, flags could be old value.<br /> It should be checked with flags of smb_lock, not flags.<br /> It will cause bug-on trap from locks_free_lock in error handling<br /> routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in smb2_lock<br /> <br /> If smb_lock-&gt;zero_len has value, -&gt;llist of smb_lock is not delete and<br /> flock is old one. It will cause use-after-free on error handling<br /> routine.