Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: clamp report_size in s32ton() to avoid undefined shift<br /> <br /> s32ton() shifts by n-1 where n is the field&amp;#39;s report_size, a value that<br /> comes directly from a HID device. The HID parser bounds report_size<br /> only to 32 clamp to the function<br /> snto32(), but s32ton() was never given the same fix as I guess syzbot<br /> hadn&amp;#39;t figured out how to fuzz a device the same way.<br /> <br /> Fix this up by just clamping the max value of n, just like snto32()<br /> does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: alps: fix NULL pointer dereference in alps_raw_event()<br /> <br /> Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event<br /> callbacks missing them") attempted to fix up the HID drivers that had<br /> missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:<br /> Fix potential NULL dereference at raw event handle"), but the alps<br /> driver was missed.<br /> <br /> Fix this up by properly checking in the hid-alps driver that it had been<br /> claimed correctly before attempting to process the raw event.

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 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.