Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: take a reference on the USB device in create_card()<br /> <br /> The caiaq driver stores a pointer to the parent USB device in<br /> cdev-&gt;chip.dev but never takes a reference on it. The card&amp;#39;s<br /> private_free callback, snd_usb_caiaq_card_free(), can run<br /> asynchronously via snd_card_free_when_closed() after the USB<br /> device has already been disconnected and freed, so any access to<br /> cdev-&gt;chip.dev in that path dereferences a freed usb_device.<br /> <br /> On top of the refcounting issue, the current card_free implementation<br /> calls usb_reset_device(cdev-&gt;chip.dev). A reset in a free callback<br /> is inappropriate: the device is going away, the call takes the<br /> device lock in a teardown context, and the reset races with the<br /> disconnect path that the callback is already cleaning up after.<br /> <br /> Take a reference on the USB device in create_card() with<br /> usb_get_dev(), drop it with usb_put_dev() in the free callback,<br /> and remove the usb_reset_device() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path<br /> <br /> smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL<br /> and the default QUERY_INFO path. The QUERY_INFO branch clamps<br /> qi.input_buffer_length to the server-reported OutputBufferLength and then<br /> copies qi.input_buffer_length bytes from qi_rsp-&gt;Buffer to userspace, but<br /> it never verifies that the flexible-array payload actually fits within<br /> rsp_iov[1].iov_len.<br /> <br /> A malicious server can return OutputBufferLength larger than the actual<br /> QUERY_INFO response, causing copy_to_user() to walk past the response<br /> buffer and expose adjacent kernel heap to userspace.<br /> <br /> Guard the QUERY_INFO copy with a bounds check on the actual Buffer<br /> payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)<br /> rather than an open-coded addition so the guard cannot overflow on<br /> 32-bit builds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate response sizes in ipc_validate_msg()<br /> <br /> ipc_validate_msg() computes the expected message size for each<br /> response type by adding (or multiplying) attacker-controlled fields<br /> from the daemon response to a fixed struct size in unsigned int<br /> arithmetic. Three cases can overflow:<br /> <br /> KSMBD_EVENT_RPC_REQUEST:<br /> msg_sz = sizeof(struct ksmbd_rpc_command) + resp-&gt;payload_sz;<br /> KSMBD_EVENT_SHARE_CONFIG_REQUEST:<br /> msg_sz = sizeof(struct ksmbd_share_config_response) +<br /> resp-&gt;payload_sz;<br /> KSMBD_EVENT_LOGIN_REQUEST_EXT:<br /> msg_sz = sizeof(struct ksmbd_login_response_ext) +<br /> resp-&gt;ngroups * sizeof(gid_t);<br /> <br /> resp-&gt;payload_sz is __u32 and resp-&gt;ngroups is __s32. Each addition<br /> can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes<br /> signed and size_t, so a negative ngroups is converted to SIZE_MAX<br /> before the multiply. A wrapped value of msg_sz that happens to<br /> equal entry-&gt;msg_sz bypasses the size check on the next line, and<br /> downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp-&gt;payload_sz,<br /> kmemdup in ksmbd_alloc_user using resp_ext-&gt;ngroups) then trust the<br /> unverified length.<br /> <br /> Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST<br /> paths to detect integer overflow without constraining functional<br /> payload size; userspace ksmbd-tools grows NDR responses in 4096-byte<br /> chunks for calls like NetShareEnumAll, so a hard transport cap is<br /> unworkable on the response side. For LOGIN_REQUEST_EXT, reject<br /> resp-&gt;ngroups outside the signed [0, NGROUPS_MAX] range up front and<br /> report the error from ipc_validate_msg() so it fires at the IPC<br /> boundary; with that bound the subsequent multiplication and addition<br /> stay well below UINT_MAX. The now-redundant ngroups check and<br /> pr_err in ksmbd_alloc_user() are removed.<br /> <br /> This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix<br /> integer overflows on 32 bit systems"), which hardened the request<br /> side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()<br /> <br /> smb_inherit_dacl() trusts the on-disk num_aces value from the parent<br /> directory&amp;#39;s DACL xattr and uses it to size a heap allocation:<br /> <br /> aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);<br /> <br /> num_aces is a u16 read from le16_to_cpu(parent_pdacl-&gt;num_aces)<br /> without checking that it is consistent with the declared pdacl_size.<br /> An authenticated client whose parent directory&amp;#39;s security.NTACL is<br /> tampered (e.g. via offline xattr corruption or a concurrent path that<br /> bypasses parse_dacl()) can present num_aces = 65535 with minimal<br /> actual ACE data. This causes a ~8 MB allocation (not kzalloc, so<br /> uninitialized) that the subsequent loop only partially populates, and<br /> may also overflow the three-way size_t multiply on 32-bit kernels.<br /> <br /> Additionally, the ACE walk loop uses the weaker<br /> offsetof(struct smb_ace, access_req) minimum size check rather than<br /> the minimum valid on-wire ACE size, and does not reject ACEs whose<br /> declared size is below the minimum.<br /> <br /> Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.<br /> A legitimate mount.cifs client creates a parent directory over SMB<br /> (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on<br /> the backing filesystem is rewritten to set num_aces = 0xFFFF while<br /> keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s<br /> hash check still passes. A subsequent SMB2 CREATE of a child under<br /> that parent drives smb2_open() into smb_inherit_dacl() (share has<br /> "vfs objects = acl_xattr" set), which fails the page allocator:<br /> <br /> WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0<br /> Workqueue: ksmbd-io handle_ksmbd_work<br /> __alloc_frozen_pages_noprof+0x46c/0x9c0<br /> ___kmalloc_large_node+0x68/0x130<br /> __kmalloc_large_node_noprof+0x24/0x70<br /> __kmalloc_noprof+0x4c9/0x690<br /> smb_inherit_dacl+0x394/0x2430<br /> smb2_open+0x595d/0xabe0<br /> handle_ksmbd_work+0x3d3/0x1140<br /> <br /> With the patch applied the added guard rejects the tampered value<br /> with -EINVAL before any large allocation runs, smb2_open() falls back<br /> to smb2_create_sd_buffer(), and the child is created with a default<br /> SD. No warning, no splat.<br /> <br /> Fix by:<br /> <br /> 1. Validating num_aces against pdacl_size using the same formula<br /> applied in parse_dacl().<br /> <br /> 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with<br /> kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe<br /> allocation.<br /> <br /> 3. Tightening the per-ACE loop guard to require the minimum valid<br /> ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and<br /> rejecting under-sized ACEs, matching the hardening in<br /> smb_check_perm_dacl() and parse_dacl().<br /> <br /> v1 -&gt; v2:<br /> - Replace the synthetic test-module splat in the changelog with a<br /> real-path UML + KASAN reproduction driven through mount.cifs and<br /> SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name<br /> in v1 since it does not exist in ksmbd.<br /> - Drop the commit-hash citation from the code comment per Namjae&amp;#39;s<br /> review; keep the parse_dacl() pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment<br /> <br /> smb2_get_ea() applies 4-byte alignment padding via memset() after<br /> writing each EA entry. The bounds check on buf_free_len is performed<br /> before the value memcpy, but the alignment memset fires unconditionally<br /> afterward with no check on remaining space.<br /> <br /> When the EA value exactly fills the remaining buffer (buf_free_len == 0<br /> after value subtraction), the alignment memset writes 1-3 NUL bytes<br /> past the buf_free_len boundary. In compound requests where the response<br /> buffer is shared across commands, the first command (e.g., READ) can<br /> consume most of the buffer, leaving a tight remainder for the QUERY_INFO<br /> EA response. The alignment memset then overwrites past the physical<br /> kvmalloc allocation into adjacent kernel heap memory.<br /> <br /> Add a bounds check before the alignment memset to ensure buf_free_len<br /> can accommodate the padding bytes.<br /> <br /> This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix<br /> potencial OOB in get_file_all_info() for compound requests") and<br /> commit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compound<br /> requests"), both of which added bounds checks before unconditional<br /> writes in QUERY_INFO response handlers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: use check_add_overflow() to prevent u16 DACL size overflow<br /> <br /> set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes<br /> in u16 variables. When a file has many POSIX ACL entries, the<br /> accumulated size can wrap past 65535, causing the pointer arithmetic<br /> (char *)pndace + *size to land within already-written ACEs. Subsequent<br /> writes then overwrite earlier entries, and pndacl-&gt;size gets a<br /> truncated value.<br /> <br /> Use check_add_overflow() at each accumulation point to detect the<br /> wrap before it corrupts the buffer, consistent with existing<br /> check_mul_overflow() usage elsewhere in smbacl.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: validate the whole DACL before rewriting it in cifsacl<br /> <br /> build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a<br /> server-supplied dacloffset and then use the incoming ACL to rebuild the<br /> chmod/chown security descriptor.<br /> <br /> The original fix only checked that the struct smb_acl header fits before<br /> reading dacl_ptr-&gt;size or dacl_ptr-&gt;num_aces. That avoids the immediate<br /> header-field OOB read, but the rewrite helpers still walk ACEs based on<br /> pdacl-&gt;num_aces with no structural validation of the incoming DACL body.<br /> <br /> A malicious server can return a truncated DACL that still contains a<br /> header, claims one or more ACEs, and then drive<br /> replace_sids_and_copy_aces() or set_chmod_dacl() past the validated<br /> extent while they compare or copy attacker-controlled ACEs.<br /> <br /> Factor the DACL structural checks into validate_dacl(), extend them to<br /> validate each ACE against the DACL bounds, and use the shared validator<br /> before the chmod/chown rebuild paths. parse_dacl() reuses the same<br /> validator so the read-side parser and write-side rewrite paths agree on<br /> what constitutes a well-formed incoming DACL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/packet: fix TOCTOU race on mmap&amp;#39;d vnet_hdr in tpacket_snd()<br /> <br /> In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points<br /> directly into the mmap&amp;#39;d TX ring buffer shared with userspace. The<br /> kernel validates the header via __packet_snd_vnet_parse() but then<br /> re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent<br /> userspace thread can modify the vnet_hdr fields between validation<br /> and use, bypassing all safety checks.<br /> <br /> The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr<br /> to a stack-local variable. All other vnet_hdr consumers in the kernel<br /> (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX<br /> path is the only caller of virtio_net_hdr_to_skb() that reads directly<br /> from user-controlled shared memory.<br /> <br /> Fix this by copying vnet_hdr from the mmap&amp;#39;d ring buffer to a<br /> stack-local variable before validation and use, consistent with the<br /> approach used in packet_snd() and all other callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp: Don&amp;#39;t attempt to copy CSR to userspace if PSP command failed<br /> <br /> When retrieving the PEK CSR, don&amp;#39;t attempt to copy the blob to userspace<br /> if the firmware command failed. If the failure was due to an invalid<br /> length, i.e. the userspace buffer+length was too small, copying the number<br /> of bytes _firmware_ requires will overflow the kernel-allocated buffer and<br /> leak data to userspace.<br /> <br /> BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405<br /> <br /> CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY<br /> Tainted: [U]=USER, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120<br /> print_address_description ../mm/kasan/report.c:378 [inline]<br /> print_report+0xbc/0x260 ../mm/kasan/report.c:482<br /> kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595<br /> check_region_inline ../mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200<br /> instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> copy_to_user ../include/linux/uaccess.h:236 [inline]<br /> sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872<br /> sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562<br /> vfs_ioctl ../fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl ../fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> WARN if the driver says the command succeeded, but the firmware error code<br /> says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any<br /> firwmware error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp: Don&amp;#39;t attempt to copy PDH cert to userspace if PSP command failed<br /> <br /> When retrieving the PDH cert, don&amp;#39;t attempt to copy the blobs to userspace<br /> if the firmware command failed. If the failure was due to an invalid<br /> length, i.e. the userspace buffer+length was too small, copying the number<br /> of bytes _firmware_ requires will overflow the kernel-allocated buffer and<br /> leak data to userspace.<br /> <br /> BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033<br /> <br /> CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY<br /> Tainted: [U]=USER, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120<br /> print_address_description ../mm/kasan/report.c:378 [inline]<br /> print_report+0xbc/0x260 ../mm/kasan/report.c:482<br /> kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595<br /> check_region_inline ../mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200<br /> instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> copy_to_user ../include/linux/uaccess.h:236 [inline]<br /> sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347<br /> sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568<br /> vfs_ioctl ../fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl ../fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> WARN if the driver says the command succeeded, but the firmware error code<br /> says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any<br /> firwmware error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp: Don&amp;#39;t attempt to copy ID to userspace if PSP command failed<br /> <br /> When retrieving the ID for the CPU, don&amp;#39;t attempt to copy the ID blob to<br /> userspace if the firmware command failed. If the failure was due to an<br /> invalid length, i.e. the userspace buffer+length was too small, copying<br /> the number of bytes _firmware_ requires will overflow the kernel-allocated<br /> buffer and leak data to userspace.<br /> <br /> BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388<br /> <br /> CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY<br /> Tainted: [U]=USER, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120<br /> print_address_description ../mm/kasan/report.c:378 [inline]<br /> print_report+0xbc/0x260 ../mm/kasan/report.c:482<br /> kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595<br /> check_region_inline ../mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200<br /> instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]<br /> _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]<br /> _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26<br /> copy_to_user ../include/linux/uaccess.h:236 [inline]<br /> sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222<br /> sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575<br /> vfs_ioctl ../fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl ../fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> WARN if the driver says the command succeeded, but the firmware error code<br /> says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any<br /> firwmware error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix missing validation of ticket length in non-XDR key preparsing<br /> <br /> In rxrpc_preparse(), there are two paths for parsing key payloads: the<br /> XDR path (for large payloads) and the non-XDR path (for payloads