Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix null pointer dereference in compare_guid_key()<br /> <br /> session_fd_check() walks the per-inode m_op_list during durable-handle<br /> session teardown and sets op-&gt;conn = NULL for every opinfo whose conn<br /> matched the closing session&amp;#39;s connection. The matching opinfo, however,<br /> stays linked in its per-ClientGuid lease_table_list entry&amp;#39;s lb-&gt;lease_list<br /> because destroy_lease_table() only runs on full TCP-connection teardown,<br /> not on SESSION_LOGOFF.<br /> <br /> If the same TCP connection then negotiates a fresh session with the<br /> same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and<br /> is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a<br /> lease context on a different inode, find_same_lease_key() walks<br /> lb-&gt;lease_list, reaches the stale opinfo, and calls compare_guid_key(),<br /> which unconditionally dereferences opinfo-&gt;conn-&gt;ClientGUID. The conn<br /> pointer is NULL and the kernel panics.<br /> <br /> Reproducer requires only a successful SMB2 SESSION_SETUP and a share<br /> configured with &amp;#39;durable handles = yes&amp;#39;. KASAN report on mainline<br /> 70390501d194:<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f]<br /> Workqueue: ksmbd-io handle_ksmbd_work<br /> RIP: 0010:bcmp+0x5b/0x230<br /> Call Trace:<br /> compare_guid_key+0x4b/0xd0<br /> find_same_lease_key+0x324/0x690<br /> smb2_open+0x6aea/0x8e60<br /> handle_ksmbd_work+0x796/0xee0<br /> ...<br /> <br /> Faulting address 0x348 is the offset of ClientGUID within struct<br /> ksmbd_conn, confirming opinfo-&gt;conn was NULL.<br /> <br /> Read opinfo-&gt;conn once and bail out if it has been cleared by a<br /> concurrent session_fd_check(). A half-detached opinfo cannot be the<br /> owner of an active lease, so returning 0 is the correct match result.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: require net admin for CIFS SWN netlink<br /> <br /> CIFS_GENL_CMD_SWN_NOTIFY is the userspace witness-notify command. The<br /> intended sender is the cifs.witness helper, but the generic-netlink<br /> operation currently has no capability flag, so any local process can send<br /> RESOURCE_CHANGE or CLIENT_MOVE notifications to the in-kernel witness<br /> handler.<br /> <br /> The same family exposes CIFS_GENL_MCGRP_SWN without multicast-group<br /> capability flags. Register messages sent to that group include the witness<br /> registration id and, for NTLM-authenticated mounts, the username, domain,<br /> and password attributes copied from the CIFS session. An unprivileged<br /> local process should not be able to join that group and receive those<br /> messages.<br /> <br /> Require CAP_NET_ADMIN for incoming SWN_NOTIFY commands with<br /> GENL_ADMIN_PERM, and require CAP_NET_ADMIN over the network namespace for<br /> joining the SWN multicast group with GENL_MCAST_CAP_NET_ADMIN. The<br /> cifs.witness service runs with the privileges needed for both operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()<br /> <br /> Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields")<br /> refactored cifs code to change cifs_tcp_ses_lock for tc_lock around<br /> tc_count changes.<br /> <br /> There was missing lock around tc_count increment inside<br /> smb2_find_smb_sess_tcon_unlocked().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX<br /> <br /> adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and<br /> passes it to i2c_smbus_read_block_data() to retrieve the 4-byte<br /> BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour<br /> caller buffer sizes -- it memcpy()s data.block[0] bytes from the<br /> SMBus transaction (where data.block[0] is the length byte returned by<br /> the slave device, up to I2C_SMBUS_BLOCK_MAX = 32):<br /> <br /> memcpy(values, &amp;data.block[1], data.block[0]);<br /> <br /> If the device returns any block length above 5, the call overflows<br /> the caller&amp;#39;s 5-byte stack buffer before the post-call<br /> <br /> if (ret != 4)<br /> return -EIO;<br /> <br /> check has a chance to reject the response.<br /> <br /> Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room<br /> for any well-formed SMBus block response, matching the convention used<br /> by the other i2c_smbus_read_block_data() callers in this driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: asihpi: Fix potential OOB array access at reading cache<br /> <br /> find_control() to retrieve a cached info accesses the array with the<br /> given index blindly, which may lead to an OOB array access.<br /> Add a sanity check for avoiding it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: refresh hdr pointer before ioam6_event()<br /> <br /> Reported by Sashiko:<br /> <br /> In ipv6_hop_ioam(), the hdr pointer is initialized to point into the<br /> skb&amp;#39;s linear data buffer. Later, the code calls skb_ensure_writable(),<br /> which might reallocate the buffer:<br /> <br /> if (skb_ensure_writable(skb, optoff + 2 + hdr-&gt;opt_len))<br /> goto drop;<br /> <br /> /* Trace pointer may have changed */<br /> trace = (struct ioam6_trace_hdr *)(skb_network_header(skb)<br /> + optoff + sizeof(*hdr));<br /> <br /> ioam6_fill_trace_data(skb, ns, trace, true);<br /> <br /> ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb-&gt;dev),<br /> GFP_ATOMIC, (void *)trace, hdr-&gt;opt_len - 2);<br /> <br /> If the skb is cloned or lacks sufficient linear headroom,<br /> skb_ensure_writable() will invoke pskb_expand_head(), which reallocates<br /> the skb&amp;#39;s data buffer and frees the old one, invalidating pointers to<br /> it. While the code recalculates the trace pointer immediately after the<br /> call to skb_ensure_writable(), it fails to recalculate the hdr pointer.<br /> <br /> This patch fixes the above by recalculating the hdr pointer before<br /> passing hdr-&gt;opt_len to ioam6_event(), so that we avoid any UaF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Don&amp;#39;t setup bogus iov_iter for silencing<br /> <br /> At transition to the iov_iter for PCM data transfer, we blindly<br /> applied the iov_iter setup also for silencing (i.e. data = NULL), and<br /> it leads to a calculation of bogus iov_iter. Fortunately this didn&amp;#39;t<br /> cause troubles on most of architectures but it goes wrong on RISC-V<br /> now, causing a NULL dereference.<br /> <br /> Handle the NULL data case to treat the silencing in interleaved_copy()<br /> for addressing the bug above. noninterleaved_copy() has already the<br /> NULL data handling, so it doesn&amp;#39;t need changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory: fix spurious warning when unmapping device-private/exclusive pages<br /> <br /> Device private and exclusive entries are only supported for anonymous<br /> folios. This condition is tested in __migrate_device_pages() and<br /> make_device_exclusive() using folio_test_anon(). However the unmap path<br /> tests this assumption using vma_is_anonymous().<br /> <br /> This is wrong because whilst anonymous VMAs can only contain folios where<br /> folio_test_anon() is true the opposite relation does not hold. A folio<br /> for which folio_test_anon() is true does not imply vma_is_anonymous() is<br /> true. Such a condition can occur if for example a folio is part of a<br /> private filebacked mapping.<br /> <br /> In this case vma_is_anonymous() is false as the mapping is filebacked, but<br /> folio_test_anon() may be true, thus permitting devices to migrate the<br /> folio to device private memory. This can lead to the following spurious<br /> warnings during process teardown:<br /> <br /> [ 772.737706] ------------[ cut here ]------------<br /> [ 772.739201] WARNING: mm/memory.c:1754 at unmap_page_range.cold+0x26/0x18a, CPU#17: hmm-tests/2041<br /> [ 772.742050] Modules linked in: test_hmm nvidia_uvm(O) nvidia(O)<br /> [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full)<br /> [ 772.747104] Tainted: [W]=WARN, [O]=OOT_MODULE<br /> [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 772.752117] RIP: 0010:unmap_page_range.cold+0x26/0x18a<br /> [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02<br /> [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286<br /> [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8<br /> [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08<br /> [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68<br /> [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001<br /> [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0<br /> [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000<br /> [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0<br /> [ 772.779135] Call Trace:<br /> [ 772.779792] <br /> [ 772.780317] ? dmirror_interval_invalidate+0x1a3/0x290 [test_hmm]<br /> [ 772.781873] ? vm_normal_page_pud+0x2b0/0x2b0<br /> [ 772.782992] ? __rwlock_init+0x150/0x150<br /> [ 772.784006] ? lock_release+0x216/0x2b0<br /> [ 772.785008] ? __mmu_notifier_invalidate_range_start+0x505/0x6e0<br /> [ 772.786522] ? lock_release+0x216/0x2b0<br /> [ 772.787498] ? unmap_single_vma+0xb6/0x210<br /> [ 772.788573] unmap_vmas+0x27d/0x520<br /> [ 772.789506] ? unmap_single_vma+0x210/0x210<br /> [ 772.790607] ? mas_update_gap.part.0+0x620/0x620<br /> [ 772.791834] unmap_region+0x19e/0x350<br /> [ 772.792769] ? remove_vma+0x130/0x130<br /> [ 772.793684] ? mas_alloc_nodes+0x1f2/0x300<br /> [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20<br /> [ 772.795926] ? unmap_region+0x350/0x350<br /> [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0<br /> [ 772.798018] ? lock_release+0x216/0x2b0<br /> [ 772.799024] ? vma_shrink+0x620/0x620<br /> [ 772.799983] do_vmi_munmap+0x150/0x2c0<br /> [ 772.800939] __vm_munmap+0x161/0x2c0<br /> [ 772.801872] ? expand_downwards+0xd60/0xd60<br /> [ 772.802948] ? clockevents_program_event+0x1ef/0x540<br /> [ 772.804217] ? lock_release+0x216/0x2b0<br /> [ 772.805158] __x64_sys_munmap+0x59/0x80<br /> [ 772.805776] do_syscall_64+0xfc/0x670<br /> [ 772.806336] ? irqentry_exit+0xda/0x580<br /> [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 772.807772] RIP: 0033:0x7f327cbb2717<br /> [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 3d 01 f0 ff<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free<br /> <br /> __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this<br /> flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.<br /> <br /> If we run with init_on_free, we will zero out pages during<br /> __free_pages_prepare(), to skip zeroing on the allocation path.<br /> <br /> However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will<br /> consequently not only skip clearing page content, but also skip clearing<br /> tag memory.<br /> <br /> Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that<br /> will get mapped to user space through set_pte_at() later: set_pte_at() and<br /> friends will detect that the tags have not been initialized yet<br /> (PG_mte_tagged not set), and initialize them.<br /> <br /> However, for the huge zero folio, which will be mapped through a PMD<br /> marked as special, this initialization will not be performed, ending up<br /> exposing whatever tags were still set for the pages.<br /> <br /> The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state<br /> that allocation tags are set to 0 when a page is first mapped to user<br /> space. That no longer holds with the huge zero folio when init_on_free is<br /> enabled.<br /> <br /> Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to<br /> tag_clear_highpages() whether we want to also clear page content.<br /> <br /> Invert the meaning of the tag_clear_highpages() return value to have<br /> clearer semantics.<br /> <br /> Reproduced with the huge zero folio by modifying the check_buffer_fill<br /> arm64/mte selftest to use a 2 MiB area, after making sure that pages have<br /> a non-0 tag set when freeing (note that, during boot, we will not actually<br /> initialize tags, but only set KASAN_TAG_KERNEL in the page flags).<br /> <br /> $ ./check_buffer_fill<br /> 1..20<br /> ...<br /> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory<br /> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory<br /> ...<br /> <br /> This code needs more cleanups; we&amp;#39;ll tackle that next, like<br /> decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.<br /> <br /> [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page<br /> <br /> When check_stable_address_space() fails after the PMD spinlock has<br /> been acquired via pmd_lock(), the code jumps directly to the abort<br /> label, bypassing the spin_unlock() call in unlock_abort. This causes<br /> the PMD spinlock to be permanently held, leading to a deadlock.<br /> <br /> Change the goto target from abort to unlock_abort to ensure the<br /> spinlock is always released on this error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: drop ISO_END frames received without prior ISO_START<br /> <br /> ISO data PDUs carry a packet-boundary flag indicating START, CONT, END<br /> or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing<br /> ISO_START by checking conn-&gt;rx_len before touching conn-&gt;rx_skb, but<br /> ISO_END does not.<br /> <br /> If a peer sends an ISO_END as the first packet on a fresh ISO<br /> connection, conn-&gt;rx_skb is still NULL and conn-&gt;rx_len is zero, so<br /> skb_put(conn-&gt;rx_skb, ...) dereferences NULL and oopses. For BIS,<br /> where receivers sync to a broadcaster without pairing, any broadcaster<br /> on the air can trigger this.<br /> <br /> Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment<br /> is logged and dropped instead of crashing the host.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer<br /> <br /> Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end<br /> warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure()<br /> from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the<br /> size and source-pointer arguments to l2cap_send_cmd():<br /> <br /> - struct {<br /> - struct l2cap_ecred_reconf_req req;<br /> - __le16 scid;<br /> - } pdu;<br /> + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1);<br /> ...<br /> l2cap_send_cmd(conn, chan-&gt;ident, L2CAP_ECRED_RECONF_REQ,<br /> sizeof(pdu), &amp;pdu);<br /> <br /> After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous<br /> union pdu_u plus a local pointer "pdu" pointing at it. Therefore:<br /> <br /> - sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on<br /> 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]).<br /> - &amp;pdu is the address of the local pointer&amp;#39;s stack storage, not the<br /> address of the request payload.<br /> <br /> l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls<br /> skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet<br /> body therefore contains 8 bytes copied from the kernel stack starting at<br /> &amp;pdu -- the 8 bytes overlap the pdu pointer&amp;#39;s value, leaking a kernel<br /> stack address to the paired Bluetooth peer. The intended (mtu, mps, scid)<br /> fields are not transmitted at all, so the peer rejects the request as<br /> malformed and the L2CAP_ECRED_RECONFIGURE feature itself has been broken<br /> for the local-side initiator since the introducing commit landed.<br /> <br /> The sibling site l2cap_ecred_conn_req() in the same commit was converted<br /> correctly (sizeof(*pdu) + len, pdu); only this site was missed.<br /> <br /> Restore the original semantics: pass the full flex-struct size via<br /> struct_size(pdu, scid, 1) and the pdu pointer (the struct address) as<br /> the source.<br /> <br /> Validated on a stock 7.0-based host kernel via the real call path:<br /> setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTED<br /> L2CAP_MODE_EXT_FLOWCTL socket emits an L2CAP_ECRED_RECONFIGURE_REQ<br /> whose body is 8 bytes (the on-stack pdu local&amp;#39;s value) rather than<br /> the expected 6. Three captures from fresh socket / fresh hciemu peer<br /> on the same host -- low bytes vary per call, high 0xffff confirms a<br /> kernel virtual address (KASLR-randomised stack slot, not a fixed<br /> string):<br /> <br /> RECONF_REQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff<br /> RECONF_REQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff<br /> RECONF_REQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff<br /> <br /> After this patch the body is 6 bytes carrying the expected<br /> little-endian (mtu, mps, scid).