Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Fix slab-use-after-free read in sg_release()<br /> <br /> Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30<br /> kernel/locking/lockdep.c:5838<br /> __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912<br /> sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407<br /> <br /> In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is<br /> called before releasing the open_rel_lock mutex. The kref_put() call may<br /> decrement the reference count of sfp to zero, triggering its cleanup<br /> through sg_remove_sfp(). This cleanup includes scheduling deferred work<br /> via sg_remove_sfp_usercontext(), which ultimately frees sfp.<br /> <br /> After kref_put(), sg_release() continues to unlock open_rel_lock and may<br /> reference sfp or sdp. If sfp has already been freed, this results in a<br /> slab-use-after-free error.<br /> <br /> Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the<br /> open_rel_lock mutex. This ensures:<br /> <br /> - No references to sfp or sdp occur after the reference count is<br /> decremented.<br /> <br /> - Cleanup functions such as sg_remove_sfp() and<br /> sg_remove_sfp_usercontext() can safely execute without impacting the<br /> mutex handling in sg_release().<br /> <br /> The fix has been tested and validated by syzbot. This patch closes the<br /> bug reported at the following syzkaller link and ensures proper<br /> sequencing of resource cleanup and mutex operations, eliminating the<br /> risk of use-after-free errors in sg_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg<br /> <br /> The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging<br /> tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.<br /> <br /> Potential problems with this strategy are as follows:<br /> <br /> - If the actual sent bytes are smaller than tosend, we need to charge some<br /> bytes back, as in line 487, which is okay but seems not clean.<br /> <br /> - When tosend is set to apply_bytes, as in line 417, and (ret sg.size - apply_bytes) bytes.<br /> <br /> [...]<br /> 415 tosend = msg-&gt;sg.size;<br /> 416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes apply_bytes;<br /> [...]<br /> 443 sk_msg_return(sk, msg, tosend);<br /> 444 release_sock(sk);<br /> 446 origsize = msg-&gt;sg.size;<br /> 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,<br /> 448 msg, tosend, flags);<br /> 449 sent = origsize - msg-&gt;sg.size;<br /> [...]<br /> 454 lock_sock(sk);<br /> 455 if (unlikely(ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU<br /> <br /> Commit<br /> <br /> 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")<br /> <br /> adds functionality that architectures can use to optionally allocate and<br /> build cacheinfo early during boot. Commit<br /> <br /> 6539cffa9495 ("cacheinfo: Add arch specific early level initializer")<br /> <br /> lets secondary CPUs correct (and reallocate memory) cacheinfo data if<br /> needed.<br /> <br /> If the early build functionality is not used and cacheinfo does not need<br /> correction, memory for cacheinfo is never allocated. x86 does not use<br /> the early build functionality. Consequently, during the cacheinfo CPU<br /> hotplug callback, last_level_cache_is_valid() attempts to dereference<br /> a NULL pointer:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000100<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEPMT SMP NOPTI<br /> CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1<br /> RIP: 0010: last_level_cache_is_valid+0x95/0xe0a<br /> <br /> Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback<br /> if not done earlier.<br /> <br /> Moreover, before determining the validity of the last-level cache info,<br /> ensure that it has been allocated. Simply checking for non-zero<br /> cache_leaves() is not sufficient, as some architectures (e.g., Intel<br /> processors) have non-zero cache_leaves() before allocation.<br /> <br /> Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().<br /> This function iterates over all online CPUs. However, a CPU may have come<br /> online recently, but its cacheinfo may not have been allocated yet.<br /> <br /> While here, remove an unnecessary indentation in allocate_cache_info().<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx: gpcv2: Adjust delay after power up handshake<br /> <br /> The udelay(5) is not enough, sometimes below kernel panic<br /> still be triggered:<br /> <br /> [ 4.012973] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 4.012976] CPU: 2 UID: 0 PID: 186 Comm: (udev-worker) Not tainted 6.12.0-rc2-0.0.0-devel-00004-g8b1b79e88956 #1<br /> [ 4.012982] Hardware name: Toradex Verdin iMX8M Plus WB on Dahlia Board (DT)<br /> [ 4.012985] Call trace:<br /> [...]<br /> [ 4.013029] arm64_serror_panic+0x64/0x70<br /> [ 4.013034] do_serror+0x3c/0x70<br /> [ 4.013039] el1h_64_error_handler+0x30/0x54<br /> [ 4.013046] el1h_64_error+0x64/0x68<br /> [ 4.013050] clk_imx8mp_audiomix_runtime_resume+0x38/0x48<br /> [ 4.013059] __genpd_runtime_resume+0x30/0x80<br /> [ 4.013066] genpd_runtime_resume+0x114/0x29c<br /> [ 4.013073] __rpm_callback+0x48/0x1e0<br /> [ 4.013079] rpm_callback+0x68/0x80<br /> [ 4.013084] rpm_resume+0x3bc/0x6a0<br /> [ 4.013089] __pm_runtime_resume+0x50/0x9c<br /> [ 4.013095] pm_runtime_get_suppliers+0x60/0x8c<br /> [ 4.013101] __driver_probe_device+0x4c/0x14c<br /> [ 4.013108] driver_probe_device+0x3c/0x120<br /> [ 4.013114] __driver_attach+0xc4/0x200<br /> [ 4.013119] bus_for_each_dev+0x7c/0xe0<br /> [ 4.013125] driver_attach+0x24/0x30<br /> [ 4.013130] bus_add_driver+0x110/0x240<br /> [ 4.013135] driver_register+0x68/0x124<br /> [ 4.013142] __platform_driver_register+0x24/0x30<br /> [ 4.013149] sdma_driver_init+0x20/0x1000 [imx_sdma]<br /> [ 4.013163] do_one_initcall+0x60/0x1e0<br /> [ 4.013168] do_init_module+0x5c/0x21c<br /> [ 4.013175] load_module+0x1a98/0x205c<br /> [ 4.013181] init_module_from_file+0x88/0xd4<br /> [ 4.013187] __arm64_sys_finit_module+0x258/0x350<br /> [ 4.013194] invoke_syscall.constprop.0+0x50/0xe0<br /> [ 4.013202] do_el0_svc+0xa8/0xe0<br /> [ 4.013208] el0_svc+0x3c/0x140<br /> [ 4.013215] el0t_64_sync_handler+0x120/0x12c<br /> [ 4.013222] el0t_64_sync+0x190/0x194<br /> [ 4.013228] SMP: stopping secondary CPUs<br /> <br /> The correct way is to wait handshake, but it needs BUS clock of<br /> BLK-CTL be enabled, which is in separate driver. So delay is the<br /> only option here. The udelay(10) is a data got by experiment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: qcom: Only free platform MSIs when ESI is enabled<br /> <br /> Otherwise, it will result in a NULL pointer dereference as below:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> Call trace:<br /> mutex_lock+0xc/0x54<br /> platform_device_msi_free_irqs_all+0x14/0x20<br /> ufs_qcom_remove+0x34/0x48 [ufs_qcom]<br /> platform_remove+0x28/0x44<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0xd8/0x178<br /> driver_detach+0x50/0x9c<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom]<br /> __arm64_sys_delete_module+0x180/0x260<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xdc<br /> el0t_64_sync_handler+0xc0/0xc4<br /> el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Cancel RTC work during ufshcd_remove()<br /> <br /> Currently, RTC work is only cancelled during __ufshcd_wl_suspend(). When<br /> ufshcd is removed in ufshcd_remove(), RTC work is not cancelled. Due to<br /> this, any further trigger of the RTC work after ufshcd_remove() would<br /> result in a NULL pointer dereference as below:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000002a4<br /> Workqueue: events ufshcd_rtc_work<br /> Call trace:<br /> _raw_spin_lock_irqsave+0x34/0x8c<br /> pm_runtime_get_if_active+0x24/0xb4<br /> ufshcd_rtc_work+0x124/0x19c<br /> process_scheduled_works+0x18c/0x2d8<br /> worker_thread+0x144/0x280<br /> kthread+0x11c/0x128<br /> ret_from_fork+0x10/0x20<br /> <br /> Since RTC work accesses the ufshcd internal structures, it should be cancelled<br /> when ufshcd is removed. So do that in ufshcd_remove(), as per the order in<br /> ufshcd_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix out_fput in iommufd_fault_alloc()<br /> <br /> As fput() calls the file-&gt;f_op-&gt;release op, where fault obj and ictx are<br /> getting released, there is no need to release these two after fput() one<br /> more time, which would result in imbalanced refcounts:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 48 PID: 2369 at lib/refcount.c:31 refcount_warn_saturate+0x60/0x230<br /> Call trace:<br /> refcount_warn_saturate+0x60/0x230 (P)<br /> refcount_warn_saturate+0x60/0x230 (L)<br /> iommufd_fault_fops_release+0x9c/0xe0 [iommufd]<br /> ...<br /> VFS: Close: file count is 0 (f_op=iommufd_fops [iommufd])<br /> WARNING: CPU: 48 PID: 2369 at fs/open.c:1507 filp_flush+0x3c/0xf0<br /> Call trace:<br /> filp_flush+0x3c/0xf0 (P)<br /> filp_flush+0x3c/0xf0 (L)<br /> __arm64_sys_close+0x34/0x98<br /> ...<br /> imbalanced put on file reference count<br /> WARNING: CPU: 48 PID: 2369 at fs/file.c:74 __file_ref_put+0x100/0x138<br /> Call trace:<br /> __file_ref_put+0x100/0x138 (P)<br /> __file_ref_put+0x100/0x138 (L)<br /> __fput_sync+0x4c/0xd0<br /> <br /> Drop those two lines to fix the warnings above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix OOB devmap writes when deleting elements<br /> <br /> Jordy reported issue against XSKMAP which also applies to DEVMAP - the<br /> index used for accessing map entry, due to being a signed integer,<br /> causes the OOB writes. Fix is simple as changing the type from int to<br /> u32, however, when compared to XSKMAP case, one more thing needs to be<br /> addressed.<br /> <br /> When map is released from system via dev_map_free(), we iterate through<br /> all of the entries and an iterator variable is also an int, which<br /> implies OOB accesses. Again, change it to be u32.<br /> <br /> Example splat below:<br /> <br /> [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000<br /> [ 160.731662] #PF: supervisor read access in kernel mode<br /> [ 160.736876] #PF: error_code(0x0000) - not-present page<br /> [ 160.742095] PGD 0 P4D 0<br /> [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP<br /> [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487<br /> [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred<br /> [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170<br /> [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff<br /> [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202<br /> [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024<br /> [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000<br /> [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001<br /> [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122<br /> [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000<br /> [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000<br /> [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0<br /> [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 160.874092] PKRU: 55555554<br /> [ 160.876847] Call Trace:<br /> [ 160.879338] <br /> [ 160.881477] ? __die+0x20/0x60<br /> [ 160.884586] ? page_fault_oops+0x15a/0x450<br /> [ 160.888746] ? search_extable+0x22/0x30<br /> [ 160.892647] ? search_bpf_extables+0x5f/0x80<br /> [ 160.896988] ? exc_page_fault+0xa9/0x140<br /> [ 160.900973] ? asm_exc_page_fault+0x22/0x30<br /> [ 160.905232] ? dev_map_free+0x77/0x170<br /> [ 160.909043] ? dev_map_free+0x58/0x170<br /> [ 160.912857] bpf_map_free_deferred+0x51/0x90<br /> [ 160.917196] process_one_work+0x142/0x370<br /> [ 160.921272] worker_thread+0x29e/0x3b0<br /> [ 160.925082] ? rescuer_thread+0x4b0/0x4b0<br /> [ 160.929157] kthread+0xd4/0x110<br /> [ 160.932355] ? kthread_park+0x80/0x80<br /> [ 160.936079] ret_from_fork+0x2d/0x50<br /> [ 160.943396] ? kthread_park+0x80/0x80<br /> [ 160.950803] ret_from_fork_asm+0x11/0x20<br /> [ 160.958482]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp_mst: Fix MST sideband message body length check<br /> <br /> Fix the MST sideband message body length check, which must be at least 1<br /> byte accounting for the message body CRC (aka message data CRC) at the<br /> end of the message.<br /> <br /> This fixes a case where an MST branch device returns a header with a<br /> correct header CRC (indicating a correctly received body length), with<br /> the body length being incorrectly set to 0. This will later lead to a<br /> memory corruption in drm_dp_sideband_append_payload() and the following<br /> errors in dmesg:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25<br /> index -1 is out of range for type &amp;#39;u8 [48]&amp;#39;<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]<br /> <br /> memcpy: detected field-spanning write (size 18446744073709551615) of single field "&amp;msg-&gt;msg[msg-&gt;curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()<br /> <br /> Syzbot reported that when searching for records in a directory where the<br /> inode&amp;#39;s i_size is corrupted and has a large value, memory access outside<br /> the folio/page range may occur, or a use-after-free bug may be detected if<br /> KASAN is enabled.<br /> <br /> This is because nilfs_last_byte(), which is called by nilfs_find_entry()<br /> and others to calculate the number of valid bytes of directory data in a<br /> page from i_size and the page index, loses the upper 32 bits of the 64-bit<br /> size information due to an inappropriate type of local variable to which<br /> the i_size value is assigned.<br /> <br /> This caused a large byte offset value due to underflow in the end address<br /> calculation in the calling nilfs_find_entry(), resulting in memory access<br /> that exceeds the folio/page size.<br /> <br /> Fix this issue by changing the type of the local variable causing the bit<br /> loss from "unsigned int" to "u64". The return value of nilfs_last_byte()<br /> is also of type "unsigned int", but it is truncated so as not to exceed<br /> PAGE_SIZE and no bit loss occurs, so no change is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: sysfs: Prevent div by zero<br /> <br /> Prevent a division by 0 when monitoring is not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix use after free on unload<br /> <br /> System crash is observed with stack trace warning of use after<br /> free. There are 2 signals to tell dpc_thread to terminate (UNLOADING<br /> flag and kthread_stop).<br /> <br /> On setting the UNLOADING flag when dpc_thread happens to run at the time<br /> and sees the flag, this causes dpc_thread to exit and clean up<br /> itself. When kthread_stop is called for final cleanup, this causes use<br /> after free.<br /> <br /> Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop<br /> as the main signal to exit dpc_thread.<br /> <br /> [596663.812935] kernel BUG at mm/slub.c:294!<br /> [596663.812950] invalid opcode: 0000 [#1] SMP PTI<br /> [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1<br /> [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012<br /> [596663.812974] RIP: 0010:__slab_free+0x17d/0x360<br /> <br /> ...<br /> [596663.813008] Call Trace:<br /> [596663.813022] ? __dentry_kill+0x121/0x170<br /> [596663.813030] ? _cond_resched+0x15/0x30<br /> [596663.813034] ? _cond_resched+0x15/0x30<br /> [596663.813039] ? wait_for_completion+0x35/0x190<br /> [596663.813048] ? try_to_wake_up+0x63/0x540<br /> [596663.813055] free_task+0x5a/0x60<br /> [596663.813061] kthread_stop+0xf3/0x100<br /> [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]