Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: proc: size address buffers for %pISpc output<br /> <br /> The AF_RXRPC procfs helpers format local and remote socket addresses into<br /> fixed 50-byte stack buffers with "%pISpc".<br /> <br /> That is too small for the longest current-tree IPv6-with-port form the<br /> formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a<br /> dotted-quad tail not only for v4mapped addresses, but also for ISATAP<br /> addresses via ipv6_addr_is_isatap().<br /> <br /> As a result, a case such as<br /> <br /> [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535<br /> <br /> is possible with the current formatter. That is 50 visible characters, so<br /> 51 bytes including the trailing NUL, which does not fit in the existing<br /> char[50] buffers used by net/rxrpc/proc.c.<br /> <br /> Size the buffers from the formatter&amp;#39;s maximum textual form and switch the<br /> call sites to scnprintf().<br /> <br /> Changes since v1:<br /> - correct the changelog to cite the actual maximum current-tree case<br /> explicitly<br /> - frame the proof around the ISATAP formatting path instead of the earlier<br /> mapped-v4 example

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix buffer overread in rxgk_do_verify_authenticator()<br /> <br /> Fix rxgk_do_verify_authenticator() to check the buffer size before checking<br /> the nonce.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix leak of rxgk context in rxgk_verify_response()<br /> <br /> Fix rxgk_verify_response() to clean up the rxgk context it creates.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix integer overflow in rxgk_verify_response()<br /> <br /> In rxgk_verify_response(), there&amp;#39;s a potential integer overflow due to<br /> rounding up token_len before checking it, thereby allowing the length check to<br /> be bypassed.<br /> <br /> Fix this by checking the unrounded value against len too (len is limited as<br /> the response must fit in a single UDP packet).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: fix reference count leak in rxrpc_server_keyring()<br /> <br /> This patch fixes a reference count leak in rxrpc_server_keyring()<br /> by checking if rx-&gt;securities is already set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: fix RESPONSE authenticator parser OOB read<br /> <br /> rxgk_verify_authenticator() copies auth_len bytes into a temporary<br /> buffer and then passes p + auth_len as the parser limit to<br /> rxgk_do_verify_authenticator(). Since p is a __be32 *, that inflates the<br /> parser end pointer by a factor of four and lets malformed RESPONSE<br /> authenticators read past the kmalloc() buffer.<br /> <br /> Decoded from the original latest-net reproduction logs with<br /> scripts/decode_stacktrace.sh:<br /> <br /> BUG: KASAN: slab-out-of-bounds in rxgk_verify_response()<br /> Call Trace:<br /> dump_stack_lvl() [lib/dump_stack.c:123]<br /> print_report() [mm/kasan/report.c:379 mm/kasan/report.c:482]<br /> kasan_report() [mm/kasan/report.c:597]<br /> rxgk_verify_response()<br /> [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167<br /> net/rxrpc/rxgk.c:1274]<br /> rxrpc_process_connection()<br /> [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364<br /> net/rxrpc/conn_event.c:386]<br /> process_one_work() [kernel/workqueue.c:3281]<br /> worker_thread()<br /> [kernel/workqueue.c:3353 kernel/workqueue.c:3440]<br /> kthread() [kernel/kthread.c:436]<br /> ret_from_fork() [arch/x86/kernel/process.c:164]<br /> <br /> Allocated by task 54:<br /> rxgk_verify_response()<br /> [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155<br /> net/rxrpc/rxgk.c:1274]<br /> rxrpc_process_connection()<br /> [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364<br /> net/rxrpc/conn_event.c:386]<br /> <br /> Convert the byte count to __be32 units before constructing the parser<br /> limit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: tdfxfb: 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 /> 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.