Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc<br /> <br /> The kernel ASN.1 BER decoder calls action callbacks incrementally as it<br /> walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken<br /> [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates<br /> conn-&gt;mechToken immediately via kmemdup_nul(). If a later element in<br /> the same blob is malformed, then the decoder will return nonzero after<br /> the allocation is already live. This could happen if mechListMIC [3]<br /> overrunse the enclosing SEQUENCE.<br /> <br /> decode_negotiation_token() then sets conn-&gt;use_spnego = false because<br /> both the negTokenInit and negTokenTarg grammars failed. The cleanup at<br /> the bottom of smb2_sess_setup() is gated on use_spnego:<br /> <br /> if (conn-&gt;use_spnego &amp;&amp; conn-&gt;mechToken) {<br /> kfree(conn-&gt;mechToken);<br /> conn-&gt;mechToken = NULL;<br /> }<br /> <br /> so the kfree is skipped, causing the mechToken to never be freed.<br /> <br /> This codepath is reachable pre-authentication, so untrusted clients can<br /> cause slow memory leaks on a server without even being properly<br /> authenticated.<br /> <br /> Fix this up by not checking check for use_spnego, as it&amp;#39;s not required,<br /> so the memory will always be properly freed. At the same time, always<br /> free the memory in ksmbd_conn_free() incase some other failure path<br /> forgot to free it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: require 3 sub-authorities before reading sub_auth[2]<br /> <br /> parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on<br /> match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is<br /> the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares<br /> only min(num_subauth, 2) sub-authorities so a client SID with<br /> num_subauth = 2 and sub_auth = {88, 3} will match.<br /> <br /> If num_subauth = 2 and the ACE is placed at the very end of the security<br /> descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The<br /> out-of-band bytes will then be masked to the low 9 bits and applied as<br /> the file&amp;#39;s POSIX mode, probably not something that is good to have<br /> happen.<br /> <br /> Fix this up by forcing the SID to actually carry a third sub-authority<br /> before reading it at all.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate EaNameLength in smb2_get_ea()<br /> <br /> smb2_get_ea() reads ea_req-&gt;EaNameLength from the client request and<br /> passes it directly to strncmp() as the comparison length without<br /> verifying that the length of the name really is the size of the input<br /> buffer received.<br /> <br /> Fix this up by properly checking the size of the name based on the value<br /> received and the overall size of the request, to prevent a later<br /> strncmp() call to use the length as a "trusted" size of the buffer.<br /> Without this check, uninitialized heap values might be slowly leaked to<br /> the client.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix off-by-8 bounds check in check_wsl_eas()<br /> <br /> The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA<br /> name and value, but ea_data sits at offset sizeof(struct<br /> smb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp()<br /> later reads ea-&gt;ea_data[0..nlen-1] and the value bytes follow at<br /> ea_data[nlen+1..nlen+vlen], so the actual end is ea-&gt;ea_data + nlen + 1<br /> + vlen. Isn&amp;#39;t pointer math fun?<br /> <br /> The earlier check (u8 *)ea &gt; end - sizeof(*ea) only guarantees the<br /> 8-byte header is in bounds, but since the last EA is placed within 8<br /> bytes of the end of the response, the name and value bytes are read past<br /> the end of iov.<br /> <br /> Fix this mess all up by using ea-&gt;ea_data as the base for the bounds<br /> check.<br /> <br /> An "untrusted" server can use this to leak up to 8 bytes of kernel heap<br /> into the EA name comparison and influence which WSL xattr the data is<br /> interpreted as.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list()<br /> <br /> smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(),<br /> so we should not call it again after post_sendmsg()<br /> moved it to the batch list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: validate number_of_packets in usbip_pack_ret_submit()<br /> <br /> When a USB/IP client receives a RET_SUBMIT response,<br /> usbip_pack_ret_submit() unconditionally overwrites<br /> urb-&gt;number_of_packets from the network PDU. This value is<br /> subsequently used as the loop bound in usbip_recv_iso() and<br /> usbip_pad_iso() to iterate over urb-&gt;iso_frame_desc[], a flexible<br /> array whose size was fixed at URB allocation time based on the<br /> *original* number_of_packets from the CMD_SUBMIT.<br /> <br /> A malicious USB/IP server can set number_of_packets in the response<br /> to a value larger than what was originally submitted, causing a heap<br /> out-of-bounds write when usbip_recv_iso() writes to<br /> urb-&gt;iso_frame_desc[i] beyond the allocated region.<br /> <br /> KASAN confirmed this with kernel 7.0.0-rc5:<br /> <br /> BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640<br /> Write of size 4 at addr ffff888106351d40 by task vhci_rx/69<br /> <br /> The buggy address is located 0 bytes to the right of<br /> allocated 320-byte region [ffff888106351c00, ffff888106351d40)<br /> <br /> The server side (stub_rx.c) and gadget side (vudc_rx.c) already<br /> validate number_of_packets in the CMD_SUBMIT path since commits<br /> c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle<br /> malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden<br /> CMD_SUBMIT path to handle malicious input"). The server side validates<br /> against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.<br /> On the client side we have the original URB, so we can use the tighter<br /> bound: the response must not exceed the original number_of_packets.<br /> <br /> This mirrors the existing validation of actual_length against<br /> transfer_buffer_length in usbip_recv_xbuff(), which checks the<br /> response value against the original allocation size.<br /> <br /> Kelvin Mbogo&amp;#39;s series ("usb: usbip: fix integer overflow in<br /> usbip_recv_iso()", v2) hardens the receive-side functions themselves;<br /> this patch complements that work by catching the bad value at its<br /> source -- in usbip_pack_ret_submit() before the overwrite -- and<br /> using the tighter per-URB allocation bound rather than the global<br /> USBIP_MAX_ISO_PACKETS limit.<br /> <br /> Fix this by checking rpdu-&gt;number_of_packets against<br /> urb-&gt;number_of_packets in usbip_pack_ret_submit() before the<br /> overwrite. On violation, clamp to zero so that usbip_recv_iso() and<br /> usbip_pad_iso() safely return early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: sm750fb: fix division by zero in ps_to_hz()<br /> <br /> ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating<br /> that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO<br /> causes a division by zero.<br /> <br /> Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent<br /> with other framebuffer drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix device leak on probe failure<br /> <br /> Driver core holds a reference to the USB interface and its parent USB<br /> device while the interface is bound to a driver and there is no need to<br /> take additional references unless the structures are needed after<br /> disconnect.<br /> <br /> This driver takes a reference to the USB device during probe but does<br /> not to release it on all probe errors (e.g. when descriptor parsing<br /> fails).<br /> <br /> Drop the redundant device reference to fix the leak, reduce cargo<br /> culting, make it easier to spot drivers where an extra reference is<br /> needed, and reduce the risk of further memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO<br /> <br /> Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide<br /> by zero error"), we also need to prevent that same crash from happening<br /> in the udlfb driver as it uses pixclock directly when dividing, which<br /> will crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_hid: don&amp;#39;t call cdev_init while cdev in use<br /> <br /> When calling unbind, then bind again, cdev_init reinitialized the cdev,<br /> even though there may still be references to it. That&amp;#39;s the case when<br /> the /dev/hidg* device is still opened. This obviously unsafe behavior<br /> like oopes.<br /> <br /> This fixes this by using cdev_alloc to put the cdev on the heap. That<br /> way, we can simply allocate a new one in hidg_bind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/xe: Reorganize the init to decouple migration from reset<br /> <br /> Attempting to issue reset on VF devices that don&amp;#39;t support migration<br /> leads to the following:<br /> <br /> BUG: unable to handle page fault for address: 00000000000011f8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy)<br /> Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<br /> RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe]<br /> Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89<br /> RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202<br /> RAX: ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101a48800<br /> R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0<br /> FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci]<br /> pci_dev_restore+0x3b/0x80<br /> pci_reset_function+0x109/0x140<br /> reset_store+0x5c/0xb0<br /> dev_attr_store+0x17/0x40<br /> sysfs_kf_write+0x72/0x90<br /> kernfs_fop_write_iter+0x161/0x1f0<br /> vfs_write+0x261/0x440<br /> ksys_write+0x69/0xf0<br /> __x64_sys_write+0x19/0x30<br /> x64_sys_call+0x259/0x26e0<br /> do_syscall_64+0xcb/0x1500<br /> ? __fput+0x1a2/0x2d0<br /> ? fput_close_sync+0x3d/0xa0<br /> ? __x64_sys_close+0x3e/0x90<br /> ? x64_sys_call+0x1b7c/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? __task_pid_nr_ns+0x68/0x100<br /> ? __do_sys_getpid+0x1d/0x30<br /> ? x64_sys_call+0x10b5/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? putname+0x41/0x90<br /> ? do_faccessat+0x1e8/0x300<br /> ? __x64_sys_access+0x1c/0x30<br /> ? x64_sys_call+0x1822/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? tick_program_event+0x43/0xa0<br /> ? hrtimer_interrupt+0x126/0x260<br /> ? irqentry_exit+0xb2/0x710<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7877d5f1c5a4<br /> Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89<br /> RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4<br /> RDX: 0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009<br /> RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9<br /> R13: 0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0<br /> <br /> <br /> This is caused by the fact that some of the xe_vfio_pci_core_device<br /> members needed for handling reset are only initialized as part of<br /> migration init.<br /> <br /> Fix the problem by reorganizing the code to decouple VF init from<br /> migration init.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Limit PTP to a single page<br /> <br /> Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256<br /> playback streams, but the additional pages are not used by the card<br /> correctly. The CT20K2 hardware already has multiple VMEM_PTPAL<br /> registers, but using them separately would require refactoring the<br /> entire virtual memory allocation logic.<br /> <br /> ct_vm_map() always uses PTEs in vm-&gt;ptp[0].area regardless of<br /> CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When<br /> aggregate memory allocations exceed this limit, ct_vm_map() tries to<br /> access beyond the allocated space and causes a page fault:<br /> <br /> BUG: unable to handle page fault for address: ffffd4ae8a10a000<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]<br /> Call Trace:<br /> atc_pcm_playback_prepare+0x225/0x3b0<br /> ct_pcm_playback_prepare+0x38/0x60<br /> snd_pcm_do_prepare+0x2f/0x50<br /> snd_pcm_action_single+0x36/0x90<br /> snd_pcm_action_nonatomic+0xbf/0xd0<br /> snd_pcm_ioctl+0x28/0x40<br /> __x64_sys_ioctl+0x97/0xe0<br /> do_syscall_64+0x81/0x610<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count<br /> remain unchanged.