Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: fireworks: bound device-supplied status before string array lookup<br /> <br /> The status field in an EFW response is a 32-bit value supplied by the<br /> firewire device. efr_status_names[] has 17 entries so a status value<br /> outside that range goes off into the weeds when looking at the %s value.<br /> <br /> Even worse, the status could return EFR_STATUS_INCOMPLETE which is<br /> 0x80000000, and is obviously not in that array of potential strings.<br /> <br /> Fix this up by properly bounding the index against the array size and<br /> printing "unknown" if it&amp;#39;s not recognized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0<br /> <br /> A malicious USB device with the TASCAM US-144MKII device id can have a<br /> configuration containing bInterfaceNumber=1 but no interface 0. USB<br /> configuration descriptors are not required to assign interface numbers<br /> sequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which will<br /> then be dereferenced directly.<br /> <br /> Fix this up by checking the return value properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnge: return after auxiliary_device_uninit() in error path<br /> <br /> When auxiliary_device_add() fails, the error block calls<br /> auxiliary_device_uninit() but does not return. The uninit drops the<br /> last reference and synchronously runs bnge_aux_dev_release(), which sets<br /> bd-&gt;auxr_dev = NULL and frees the underlying object. The subsequent<br /> bd-&gt;auxr_dev-&gt;net = bd-&gt;netdev then dereferences NULL, which is not a<br /> good thing to have happen when trying to clean up from an error.<br /> <br /> Add the missing return, as the auxiliary bus documentation states is a<br /> requirement (seems that LLM tools read documentation better than humans<br /> do...)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: digital: Bounds check NFC-A cascade depth in SDD response handler<br /> <br /> The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3<br /> or 4 bytes to target-&gt;nfcid1 on each round, but the number of cascade<br /> rounds is controlled entirely by the peer device. The peer sets the<br /> cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the<br /> cascade-incomplete bit in the SEL_RES (deciding whether another round<br /> follows).<br /> <br /> ISO 14443-3 limits NFC-A to three cascade levels and target-&gt;nfcid1 is<br /> sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver<br /> actually enforces this. This means a malicious peer can keep the<br /> cascade running, writing past the heap-allocated nfc_target with each<br /> round.<br /> <br /> Fix this by rejecting the response when the accumulated UID would exceed<br /> the buffer.<br /> <br /> Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")<br /> fixed similar missing checks against the same field on the NCI path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()<br /> <br /> A malicious USB device claiming to be a CDC Phonet modem can overflow<br /> the skb_shared_info-&gt;frags[] array by sending an unbounded sequence of<br /> full-page bulk transfers.<br /> <br /> Drop the skb and increment the length error when the frag limit is<br /> reached. This matches the same fix that commit f0813bcd2d9d ("net:<br /> wwan: t7xx: fix potential skb-&gt;frags overflow in RX path") did for the<br /> t7xx driver.

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.