Vulnerabilities

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 oversized RESPONSE authenticator length check<br /> <br /> rxgk_verify_response() decodes auth_len from the packet and is supposed<br /> to verify that it fits in the remaining bytes. The existing check is<br /> inverted, so oversized RESPONSE authenticators are accepted and passed<br /> to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an<br /> impossible length and hit BUG_ON(len).<br /> <br /> Decoded from the original latest-net reproduction logs with<br /> scripts/decode_stacktrace.sh:<br /> <br /> RIP: __skb_to_sgvec()<br /> [net/core/skbuff.c:5285 (discriminator 1)]<br /> Call Trace:<br /> skb_to_sgvec() [net/core/skbuff.c:5305]<br /> rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81]<br /> rxgk_verify_response() [net/rxrpc/rxgk.c:1268]<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 /> Reject authenticator lengths that exceed the remaining packet payload.

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.

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.