Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: harden block_group::bg_list against list_del() races<br /> <br /> As far as I can tell, these calls of list_del_init() on bg_list cannot<br /> run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),<br /> as they are in transaction error paths and situations where the block<br /> group is readonly.<br /> <br /> However, if there is any chance at all of racing with mark_bg_unused(),<br /> or a different future user of bg_list, better to be safe than sorry.<br /> <br /> Otherwise we risk the following interleaving (bg_list refcount in parens)<br /> <br /> T1 (some random op) T2 (btrfs_mark_bg_unused)<br /> !list_empty(&amp;bg-&gt;bg_list); (1)<br /> list_del_init(&amp;bg-&gt;bg_list); (1)<br /> list_move_tail (1)<br /> btrfs_put_block_group (0)<br /> btrfs_delete_unused_bgs<br /> bg = list_first_entry<br /> list_del_init(&amp;bg-&gt;bg_list);<br /> btrfs_put_block_group(bg); (-1)<br /> <br /> Ultimately, this results in a broken ref count that hits zero one deref<br /> early and the real final deref underflows the refcount, resulting in a WARNING.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: st: Fix array overflow in st_setup()<br /> <br /> Change the array size to follow parms size instead of a fixed value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: Prevent integer overflow in AG size calculation<br /> <br /> The JFS filesystem calculates allocation group (AG) size using 1 bmap-&gt;db_agsize<br /> - Subsequent block allocations would reference invalid AG structures<br /> - Could lead to:<br /> - Filesystem corruption during extend operations<br /> - Kernel crashes due to invalid memory accesses<br /> - Security vulnerabilities via malformed on-disk structures<br /> <br /> Fix by casting to s64 before shifting:<br /> bmp-&gt;db_agsize = (s64)1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> page_pool: avoid infinite loop to schedule delayed worker<br /> <br /> We noticed the kworker in page_pool_release_retry() was waken<br /> up repeatedly and infinitely in production because of the<br /> buggy driver causing the inflight less than 0 and warning<br /> us in page_pool_inflight()[1].<br /> <br /> Since the inflight value goes negative, it means we should<br /> not expect the whole page_pool to get back to work normally.<br /> <br /> This patch mitigates the adverse effect by not rescheduling<br /> the kworker when detecting the inflight negative in<br /> page_pool_release_retry().<br /> <br /> [1]<br /> [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------<br /> [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages<br /> ...<br /> [Mon Feb 10 20:36:11 2025] Call Trace:<br /> [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70<br /> [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370<br /> [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0<br /> [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140<br /> [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370<br /> [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40<br /> [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40<br /> [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---<br /> Note: before this patch, the above calltrace would flood the<br /> dmesg due to repeated reschedule of release_dw kworker.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Guard Possible Null Pointer Dereference<br /> <br /> [WHY]<br /> In some situations, dc-&gt;res_pool may be null.<br /> <br /> [HOW]<br /> Check if pointer is null before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix mode1 reset crash issue<br /> <br /> If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal<br /> user space to abort the processes. After process abort exit, user queues<br /> still use the GPU to access system memory before h/w is reset while KFD<br /> cleanup worker free system memory and free VRAM.<br /> <br /> There is use-after-free race bug that KFD allocate and reuse the freed<br /> system memory, and user queue write to the same system memory to corrupt<br /> the data structure and cause driver crash.<br /> <br /> To fix this race, KFD cleanup worker terminate user queues, then flush<br /> reset_domain wq to wait for any GPU ongoing reset complete, and then<br /> free outstanding BOs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: debugfs hang_hws skip GPU with MES<br /> <br /> debugfs hang_hws is used by GPU reset test with HWS, for MES this crash<br /> the kernel with NULL pointer access because dqm-&gt;packet_mgr is not setup<br /> for MES path.<br /> <br /> Skip GPU with MES for now, MES hang_hws debugfs interface will be<br /> supported later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()<br /> <br /> Add error handling to propagate amdgpu_cgs_create_device() failures<br /> to the caller. When amdgpu_cgs_create_device() fails, release hwmgr<br /> and return -ENOMEM to prevent null pointer dereference.<br /> <br /> [v1]-&gt;[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: omapfb: Add &amp;#39;plane&amp;#39; value check<br /> <br /> Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB<br /> of the enum parameter plane.<br /> <br /> The value of this parameter is initialized in dss_init_overlays and in the<br /> current state of the code it cannot take this value so it&amp;#39;s not a real<br /> problem.<br /> <br /> For the purposes of defensive coding it wouldn&amp;#39;t be superfluous to check<br /> the parameter value, because some functions down the call stack process<br /> this value correctly and some not.<br /> <br /> For example, in dispc_ovl_setup_global_alpha it may lead to buffer<br /> overflow.<br /> <br /> Add check for this value.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: fprobe events: Fix possible UAF on modules<br /> <br /> Commit ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module<br /> refcount") moved try_module_get() from __find_tracepoint_module_cb()<br /> to find_tracepoint() caller, but that introduced a possible UAF<br /> because the module can be unloaded before try_module_get(). In this<br /> case, the module object should be freed too. Thus, try_module_get()<br /> does not only fail but may access to the freed object.<br /> <br /> To avoid that, try_module_get() in __find_tracepoint_module_cb()<br /> again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: avoid NULL pointer dereference in dbg call<br /> <br /> cifs_server_dbg() implies server to be non-NULL so<br /> move call under condition to avoid NULL pointer dereference.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pciehp: Avoid unnecessary device replacement check<br /> <br /> Hot-removal of nested PCI hotplug ports suffers from a long-standing race<br /> condition which can lead to a deadlock: A parent hotplug port acquires<br /> pci_lock_rescan_remove(), then waits for pciehp to unbind from a child<br /> hotplug port. Meanwhile that child hotplug port tries to acquire<br /> pci_lock_rescan_remove() as well in order to remove its own children.<br /> <br /> The deadlock only occurs if the parent acquires pci_lock_rescan_remove()<br /> first, not if the child happens to acquire it first.<br /> <br /> Several workarounds to avoid the issue have been proposed and discarded<br /> over the years, e.g.:<br /> <br /> https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/<br /> <br /> A proper fix is being worked on, but needs more time as it is nontrivial<br /> and necessarily intrusive.<br /> <br /> Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during<br /> system sleep") provokes more frequent occurrence of the deadlock when<br /> removing more than one Thunderbolt device during system sleep. The commit<br /> sought to detect device replacement, but also triggered on device removal.<br /> Differentiating reliably between replacement and removal is impossible<br /> because pci_get_dsn() returns 0 both if the device was removed, as well as<br /> if it was replaced with one lacking a Device Serial Number.<br /> <br /> Avoid the more frequent occurrence of the deadlock by checking whether the<br /> hotplug port itself was hot-removed. If so, there&amp;#39;s no sense in checking<br /> whether its child device was replaced.<br /> <br /> This works because the -&gt;resume_noirq() callback is invoked in top-down<br /> order for the entire hierarchy: A parent hotplug port detecting device<br /> replacement (or removal) marks all children as removed using<br /> pci_dev_set_disconnected() and a child hotplug port can then reliably<br /> detect being removed.