Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()<br /> <br /> Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using<br /> uninitialized data.<br /> <br /> Smatch warns that only 6 bytes are copied to this 8-byte (u64)<br /> variable, leaving the last two bytes uninitialized:<br /> <br /> drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()<br /> warn: not copying enough bytes for &amp;#39;&amp;le_tmp64&amp;#39; (8 vs 6 bytes)<br /> <br /> Initializing the variable at the start of the function fixes this<br /> warning and ensures predictable behavior.

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 /> smb: client: avoid double-free in smbd_free_send_io() after smbd_send_batch_flush()<br /> <br /> smbd_send_batch_flush() already calls smbd_free_send_io(),<br /> so we should not call it again after smbd_post_send()<br /> moved it to the batch list.

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 OOB reads parsing symlink error response<br /> <br /> When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()<br /> returns success without any length validation, leaving the symlink<br /> parsers as the only defense against an untrusted server.<br /> <br /> symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p-&gt;ErrorDataLength at offset<br /> 0. When the server-controlled ErrorDataLength advances p to within 1-7<br /> bytes of end, the next iteration will read past it. When the matching<br /> context is found, sym-&gt;SymLinkErrorTag is read at offset 4 from<br /> p-&gt;ErrorContextData with no check that the symlink header itself fits.<br /> <br /> smb2_parse_symlink_response() then bounds-checks the substitute name<br /> using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from<br /> iov_base. That value is computed as sizeof(smb2_err_rsp) +<br /> sizeof(smb2_symlink_err_rsp), which is correct only when<br /> ErrorContextCount == 0.<br /> <br /> With at least one error context the symlink data sits 8 bytes deeper,<br /> and each skipped non-matching context shifts it further by 8 +<br /> ALIGN(ErrorDataLength, 8). The check is too short, allowing the<br /> substitute name read to run past iov_len. The out-of-bound heap bytes<br /> are UTF-16-decoded into the symlink target and returned to userspace via<br /> readlink(2).<br /> <br /> Fix this all up by making the loops test require the full context header<br /> to fit, rejecting sym if its header runs past end, and bound the<br /> substitute name against the actual position of sym-&gt;PathBuffer rather<br /> than a fixed offset.<br /> <br /> Because sub_offs and sub_len are 16bits, the pointer math will not<br /> overflow here with the new greater-than.

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 /> usb: gadget: renesas_usb3: validate endpoint index in standard request handlers<br /> <br /> The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint<br /> number from the host-supplied wIndex without any sort of validation.<br /> Fix this up by validating the number of endpoints actually match up with<br /> the number the device has before attempting to dereference a pointer<br /> based on this math.<br /> <br /> This is just like what was done in commit ee0d382feb44 ("usb: gadget:<br /> aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()<br /> <br /> A broken/bored/mean USB host can overflow the skb_shared_info-&gt;frags[]<br /> array on a Linux gadget exposing a Phonet function by sending an<br /> unbounded sequence of full-page OUT transfers.<br /> <br /> pn_rx_complete() finalizes the skb only when req-&gt;actual length,<br /> where req-&gt;length is set to PAGE_SIZE by the gadget. If the host always<br /> sends exactly PAGE_SIZE bytes per transfer, fp-&gt;rx.skb will never be<br /> reset and each completion will add another fragment via<br /> skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),<br /> subsequent frag stores overwrite memory adjacent to the shinfo on the<br /> heap.<br /> <br /> Drop the skb and account a length error when the frag limit is reached,<br /> matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan:<br /> t7xx: fix potential skb-&gt;frags overflow in RX path").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()<br /> <br /> The block_len read from the host-supplied NTB header is checked against<br /> ntb_max but has no lower bound. When block_len is smaller than<br /> opts-&gt;ndp_size, the bounds check of:<br /> ndp_index &gt; (block_len - opts-&gt;ndp_size)<br /> will underflow producing a huge unsigned value that ndp_index can never<br /> exceed, defeating the check entirely.<br /> <br /> The same underflow occurs in the datagram index checks against block_len<br /> - opts-&gt;dpe_size. With those checks neutered, a malicious USB host can<br /> choose ndp_index and datagram offsets that point past the actual<br /> transfer, and the skb_put_data() copies adjacent kernel memory into the<br /> network skb.<br /> <br /> Fix this by rejecting block lengths that cannot hold at least the NTB<br /> header plus one NDP. This will make block_len - opts-&gt;ndp_size and<br /> block_len - opts-&gt;dpe_size both well-defined.<br /> <br /> Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed<br /> a related class of issues on the host side of NCM.

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.