Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL<br /> <br /> Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on<br /> double SMB2_CANCEL") made smb2_cancel() skip a work whose state is<br /> KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But<br /> KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same<br /> freeing producer path is reached for CLOSED too:<br /> <br /> SMB2_CLOSE on the locking handle -&gt; set_close_state_blocked_works() sets<br /> the deferred work&amp;#39;s state to KSMBD_WORK_CLOSED and wakes the smb2_lock()<br /> worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s<br /> the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes<br /> the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the<br /> cancelled branch, skips release_async_work(). The work stays on<br /> conn-&gt;async_requests with a live cancel_fn = smb2_remove_blocked_lock<br /> pointing at the freed file_lock.<br /> <br /> A subsequent SMB2_CANCEL for the same AsyncId then passes the<br /> KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so<br /> smb2_cancel() fires cancel_fn again over the freed file_lock -- the same<br /> use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL:<br /> <br /> BUG: KASAN: slab-use-after-free in __locks_delete_block<br /> __locks_delete_block<br /> locks_delete_block<br /> ksmbd_vfs_posix_lock_unblock<br /> smb2_remove_blocked_lock<br /> smb2_cancel

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()<br /> <br /> The VF2PF interrupt handler queues PF-side response work that stores a<br /> raw pointer to per-VF state (struct adf_accel_vf_info). Currently,<br /> adf_disable_sriov() destroys per-VF mutexes and frees vf_info without<br /> stopping new VF2PF work or waiting for in-flight workers to complete. A<br /> concurrently scheduled or already queued worker can then dereference<br /> freed memory.<br /> <br /> This manifests as a use-after-free when KASAN is enabled:<br /> <br /> BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0<br /> Write of size 8 at addr 0000000000000260 by task kworker/24:2/...<br /> Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat]<br /> Call Trace:<br /> kasan_report+0x119/0x140<br /> mutex_lock+0x76/0xe0<br /> adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat]<br /> adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat]<br /> adf_iov_send_resp+0x8c/0xe0 [intel_qat]<br /> process_one_work+0x6ac/0xfd0<br /> worker_thread+0x4dd/0xd30<br /> kthread+0x326/0x410<br /> ret_from_fork+0x33b/0x670<br /> <br /> Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker<br /> processing, and interrupt re-enabling during teardown. Set this flag<br /> atomically with the hardware interrupt mask inside<br /> adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE<br /> cluster MSI-X interrupt and flush the PF response workqueue before<br /> tearing down per-VF locks and state so all in-flight work completes<br /> before vf_info is destroyed.<br /> <br /> Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and<br /> unmask all VF2PF interrupts under the same lock when SR-IOV is<br /> re-enabled. This ensures the software flag and hardware state transition<br /> atomically on both the enable and disable paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: krb5 - filter out async aead implementations at alloc<br /> <br /> krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and<br /> rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL<br /> completion callback and treat any negative return from<br /> crypto_aead_{encrypt,decrypt}() as terminal, falling through to<br /> kfree_sensitive(buffer). When the encrypt_name resolves to an<br /> async AEAD instance the request returns -EINPROGRESS, the buffer<br /> is freed while the backend&amp;#39;s worker still holds a pointer, and the<br /> worker dereferences the freed slab on completion.<br /> <br /> KASAN report under UML+SLUB with a synthetic async aead backend<br /> bound to krb5-&gt;encrypt_name:<br /> <br /> BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7<br /> <br /> The helpers were written synchronously, so filter the async<br /> instances out at allocation time instead of plumbing<br /> crypto_wait_req() through every call site.<br /> <br /> Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and<br /> net/ceph/crypto.c on systems with an async AEAD provider bound to<br /> the krb5 enctype name.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB write in HT_caps_handler()<br /> <br /> HT_caps_handler() iterates pIE-&gt;length bytes and writes into<br /> HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct<br /> HT_caps_element). Because pIE-&gt;length is a raw u8 from an over-the-air<br /> 802.11 AssocResponse frame and is never validated, a malicious AP can<br /> set it up to 255, causing up to 229 bytes of out-of-bounds writes into<br /> adjacent fields of struct mlme_ext_info.<br /> <br /> Truncate the iteration count to the size of HT_caps.u.HT_cap using<br /> umin() so that data from a longer-than-expected IE is silently ignored<br /> rather than written out of bounds, preserving interoperability with APs<br /> that pad the element. An early return on oversized IEs was considered<br /> but rejected: it would bypass the pmlmeinfo-&gt;HT_caps_enable = 1<br /> assignment that precedes the loop, silently disabling HT mode for APs<br /> that append extra bytes to the HT Capabilities IE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()<br /> <br /> Three IE/attribute parsing functions have missing bounds checks.<br /> <br /> rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer<br /> without verifying that the header bytes (tag + length) are within the<br /> remaining buffer before reading them. Additionally, rtw_get_sec_ie()<br /> compares the 4-byte WPA OUI at cnt+2 without checking that at least<br /> 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at<br /> cnt+6 without checking that at least 10 bytes remain.<br /> <br /> rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at<br /> entry, before verifying that wps_ielen is large enough to contain<br /> the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside<br /> the attribute loop, get_unaligned_be16() is called on attr_ptr and<br /> attr_ptr+2 without checking that 4 bytes remain in the buffer.<br /> <br /> Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie()<br /> and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum<br /> IE length requirement, add a wps_ielen

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()<br /> <br /> Two IE parsing loops are missing the header bounds checks before they<br /> dereference pIE-&gt;length:<br /> <br /> - issue_assocreq() walks pmlmeinfo-&gt;network.ies to build the<br /> association request. If the stored IE data ends with only an<br /> element_id byte and no length byte, pIE-&gt;length is read one byte<br /> past the end of the buffer.<br /> <br /> - join_cmd_hdl() walks pnetwork-&gt;ies during station join and has<br /> the same problem under the same conditions.<br /> <br /> Both buffers are filled from AP beacon and probe-response frames, so a<br /> malicious AP that sends a truncated final IE can trigger the issue.<br /> <br /> Apply the two-guard pattern established in update_beacon_info():<br /> 1. Break if fewer than sizeof(*pIE) bytes remain.<br /> 2. Break if the IE&amp;#39;s declared data extends past the buffer end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop<br /> <br /> The IE parsing loop in update_beacon_info() advances by<br /> (pIE-&gt;length + 2) each iteration but only guards on i length from one byte past the allocated receive buffer.<br /> <br /> Additionally, even when the header bytes are in bounds, pIE-&gt;length<br /> itself can extend the data window beyond len, passing a truncated IE<br /> to the handler functions.<br /> <br /> Add two guards at the top of the loop body:<br /> 1. Break if fewer than sizeof(*pIE) bytes remain (can&amp;#39;t read header).<br /> 2. Break if the IE&amp;#39;s declared data extends past len.<br /> <br /> Also replace i += (pIE-&gt;length + 2) with i += sizeof(*pIE) + pIE-&gt;length<br /> for consistency with the sizeof(*pIE) guards added above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: eic-sprd: use raw_spinlock_t in the irq startup path<br /> <br /> sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller<br /> state through sprd_eic_update(), which takes sprd_eic-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sprd_eic_irq_unmask() -&gt; sprd_eic_update() carrier and<br /> used the original spin_lock_irqsave(&amp;sprd_eic-&gt;lock) edge. Lockdep<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]<br /> sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The<br /> locked section only serializes MMIO register updates and does not contain<br /> sleepable operations, so keeping it non-sleeping is appropriate for the<br /> irqchip callbacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete<br /> <br /> add_device_complete() runs from the hci_cmd_sync_work kworker, which<br /> holds only hci_req_sync_lock and *not* hci_dev_lock. It calls<br /> hci_conn_params_lookup() and then dereferences the returned object<br /> (params-&gt;flags) without taking hci_dev_lock:<br /> <br /> params = hci_conn_params_lookup(hdev, &amp;cp-&gt;addr.bdaddr,<br /> le_addr_type(cp-&gt;addr.type));<br /> ...<br /> device_flags_changed(NULL, hdev, &amp;cp-&gt;addr.bdaddr,<br /> cp-&gt;addr.type, hdev-&gt;conn_flags,<br /> params ? params-&gt;flags : 0);<br /> <br /> hci_conn_params_lookup() walks hdev-&gt;le_conn_params and is documented to<br /> require hdev-&gt;lock. A concurrent MGMT_OP_REMOVE_DEVICE<br /> (remove_device()), which does run under hci_dev_lock, can call<br /> hci_conn_params_free() to list_del() and kfree() the very object the<br /> lookup returned, so the subsequent params-&gt;flags read touches freed<br /> memory [0].<br /> <br /> Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of<br /> params-&gt;flags (and the matching event emission) so the lookup result<br /> cannot be freed by a concurrent remove_device() before it is used,<br /> honouring the locking contract of hci_conn_params_lookup().<br /> <br /> [0]: (trailing page/memory-state dump trimmed)<br /> BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388<br /> <br /> CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x118/0x5d8 mm/kasan/report.c:482<br /> kasan_report+0xb0/0xf4 mm/kasan/report.c:595<br /> __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378<br /> add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334<br /> process_one_work+0x628/0xd38 kernel/workqueue.c:3289<br /> process_scheduled_works kernel/workqueue.c:3372 [inline]<br /> worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453<br /> kthread+0x39c/0x444 kernel/kthread.c:436<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860<br /> <br /> Allocated by task 3401:<br /> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57<br /> kasan_save_track+0x20/0x3c mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385<br /> kmalloc_noprof include/linux/slab.h:950 [inline]<br /> kzalloc_noprof include/linux/slab.h:1188 [inline]<br /> hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279<br /> hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline]<br /> add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755<br /> hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline]<br /> hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe0/0x128 net/socket.c:742<br /> sock_write_iter+0x250/0x390 net/socket.c:1195<br /> new_sync_write fs/read_write.c:595 [inline]<br /> vfs_write+0x66c/0xab0 fs/read_write.c:688<br /> ksys_write+0x1fc/0x24c fs/read_write.c:740<br /> __do_sys_write fs/read_write.c:751 [inline]<br /> __se_sys_write fs/read_write.c:748 [inline]<br /> __arm64_sys_write+0x70/0xa4 fs/read_write.c:748<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724<br /> el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596<br /> <br /> Freed by task 3740:<br /> kasan_save_stack+0x3c/0x64 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: epf: Avoid calling pci_irq_vector() from hardirq context<br /> <br /> ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive<br /> the vector number. pci_irq_vector() calls msi_get_virq() that takes a<br /> mutex and can therefore trigger "scheduling while atomic" splats:<br /> <br /> BUG: scheduling while atomic: kworker/u33:0/55/0x00010001<br /> ...<br /> Call trace:<br /> ...<br /> schedule+0x38/0x110<br /> schedule_preempt_disabled+0x28/0x50<br /> __mutex_lock.constprop.0+0x848/0x908<br /> __mutex_lock_slowpath+0x18/0x30<br /> mutex_lock+0x4c/0x60<br /> msi_domain_get_virq+0xe8/0x138<br /> pci_irq_vector+0x2c/0x60<br /> ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf]<br /> __handle_irq_event_percpu+0x70/0x3a8<br /> handle_irq_event+0x48/0x100<br /> handle_edge_irq+0x100/0x1c8<br /> ...<br /> <br /> Cache the Linux IRQ number for vector 0 when vectors are allocated and<br /> use it as a base in the ISR. Running the ISR in a threaded IRQ handler<br /> would also avoid the problem, but that would be unnecessary here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: avoid calling post_write_mst_fixup() for invalid index_block<br /> <br /> ntfs_icx_ib_sync_write() calls post_write_mst_fixup() when ntfs_ib_write()<br /> returns an error, intending to restore the buffer after a failed write.<br /> <br /> However, ntfs_ib_write() returns an error immediately if<br /> pre_write_mst_fixup() validation fails. The caller,<br /> ntfs_icx_ib_sync_write(), interprets any error as a write failure<br /> requiring rollback. It does not differentiate between I/O errors and<br /> validation failures, and calls post_write_mst_fixup() anyway.<br /> <br /> Since post_write_mst_fixup() assumes that the index_block contents is<br /> correct, it doesn&amp;#39;t perform the boundary checks, which results in<br /> out-of-bounds memory access.<br /> <br /> An attacker can craft a malicious NTFS image with:<br /> - large index_block.usa_ofs offset, pointing outside the ntfs_record<br /> - index_block.usa_count = 0, causing integer underflow<br /> - or index_block.usa_count larger than actual number of sectors in the<br /> ntfs_record, causing out-of-bounds access<br /> <br /> KASAN reports describing the memory corruption:<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x19c/0x1d0<br /> Read of size 2 at addr ffff8881586c9018 by task p/9428<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> print_report+0x139/0x4ad<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> ? __virt_addr_valid+0x262/0x500<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> kasan_report+0xe4/0x1d0<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> post_write_mst_fixup+0x19c/0x1d0<br /> ntfs_icx_ib_sync_write+0x179/0x220<br /> ntfs_inode_sync_filename+0x83d/0x1080<br /> __ntfs_write_inode+0x1049/0x1480<br /> ntfs_file_fsync+0x131/0x9b0<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x1aa/0x1d0<br /> Write of size 2 at addr ffff8881586c91fe by task p/9428<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> print_report+0x139/0x4ad<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> ? __virt_addr_valid+0x262/0x500<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> kasan_report+0xe4/0x1d0<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> post_write_mst_fixup+0x1aa/0x1d0<br /> ntfs_icx_ib_sync_write+0x179/0x220<br /> ntfs_inode_sync_filename+0x83d/0x1080<br /> __ntfs_write_inode+0x1049/0x1480<br /> ntfs_file_fsync+0x131/0x9b0<br /> ==================================================================<br /> <br /> Let&amp;#39;s move the post_write_mst_fixup() call to ntfs_ib_write().<br /> The ntfs_ib_write() function calls pre_write_mst_fixup() at the beginning.<br /> If the index_block contents is invalid, pre_write_mst_fixup() fails and<br /> ntfs_ib_write() returns early without calling post_write_mst_fixup() on<br /> bad index_block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns<br /> <br /> In the analysis pass of $LogFile journal replay, log_replay() copies<br /> LCNs from each action log record into an existing Dirty Page Table<br /> (DPT) entry without bounding the destination index. A crafted NTFS<br /> image with DPT entry lcns_follow=1 and an action log record with<br /> lcns_follow=2 produces a kernel slab out-of-bounds write at mount<br /> time:<br /> <br /> BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60<br /> Write of size 8 at addr ffff8880095e1040 by task mount<br /> <br /> Two attacker-controlled fields can drive j+i past the allocated<br /> page_lcns[] array:<br /> <br /> 1. dp-&gt;lcns_follow (capacity) can be smaller than lrh-&gt;lcns_follow.<br /> 2. lrh-&gt;target_vcn may be smaller than dp-&gt;vcn, making the u64<br /> subtraction wrap to a huge size_t.<br /> <br /> Validate target VCN delta and per-record LCN count against the<br /> DPT entry capacity, bail via the existing out: cleanup label with<br /> -EINVAL.<br /> <br /> This mirrors the bounds-check pattern added in commit b2bc7c44ed17<br /> ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot")<br /> and commit 0ca0485e4b2e ("fs/ntfs3: validate rec-&gt;used in<br /> journal-replay file record check").