Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/edid: fix OOB read in drm_parse_tiled_block()<br /> <br /> drm_parse_tiled_block() casts the DisplayID block to a<br /> struct displayid_tiled_block and reads the full fixed layout up to<br /> tile-&gt;topology_id[7] without checking block-&gt;num_bytes. The DisplayID<br /> iterator only validates the declared payload length, so a crafted EDID<br /> can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or<br /> DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at<br /> the end of a DisplayID extension. The read then runs past the end of the<br /> exact-sized kmemdup()&amp;#39;d EDID allocation, a heap out-of-bounds read.<br /> <br /> Reject blocks shorter than the spec&amp;#39;s 22-byte tiled payload before<br /> reading the fixed struct, as drm_parse_vesa_mso_data() already does.<br /> <br /> BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update<br /> Read of size 2 at addr ffff888010077700 by task exploit/147<br /> dump_stack_lvl (lib/dump_stack.c:94 ...)<br /> print_report (mm/kasan/report.c:378 ...)<br /> kasan_report (mm/kasan/report.c:595)<br /> drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)<br /> bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)<br /> drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)<br /> status_store (drivers/gpu/drm/drm_sysfs.c:219)<br /> ...<br /> vfs_write (fs/read_write.c:595 fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: net1080: validate packet_len before pad-byte access in rx_fixup<br /> <br /> For an even packet_len, net1080_rx_fixup() reads the pad byte at<br /> skb-&gt;data[packet_len] before the skb-&gt;len != packet_len check further<br /> down, and packet_len is only bounded against NC_MAX_PACKET. A malicious<br /> NetChip 1080 device can send a short frame advertising a large even<br /> packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the<br /> skb:<br /> <br /> BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup<br /> Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14<br /> ...<br /> net1080_rx_fixup (drivers/net/usb/net1080.c:384)<br /> usbnet_bh (drivers/net/usb/usbnet.c:1589)<br /> process_one_work (kernel/workqueue.c:3322)<br /> bh_worker (kernel/workqueue.c:3708)<br /> tasklet_action (kernel/softirq.c:965)<br /> handle_softirqs (kernel/softirq.c:622)<br /> ...<br /> <br /> Reject the frame when packet_len &gt;= skb-&gt;len before reading.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()<br /> <br /> When the scatterlist ring is full or nearly full, bpf_msg_push_data()<br /> enters a copy fallback path and computes copy + len for the page<br /> allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING<br /> and both are u32, a crafted len can wrap the sum to a small value,<br /> causing an undersized allocation followed by an out-of-bounds memcpy.<br /> <br /> BUG: unable to handle page fault for address: ffffed104089a402<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> Call Trace:<br /> __asan_memcpy (mm/kasan/shadow.c:105)<br /> bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788)<br /> bpf_prog_9ed8b5711920a7d7+0x2e/0x36<br /> sk_psock_msg_verdict (net/core/skmsg.c:934)<br /> tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584)<br /> __sys_sendto (net/socket.c:2206)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Add an overflow check before the allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()<br /> <br /> bpa10x_setup() sends the vendor command 0xfc0e and passes the response<br /> to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at<br /> skb-&gt;data + 1, without checking the length:<br /> <br /> bt_dev_info(hdev, "%s", (char *)(skb-&gt;data + 1));<br /> hci_set_fw_info(hdev, "%s", skb-&gt;data + 1);<br /> <br /> A device that returns a one-byte response (status only) leaves<br /> skb-&gt;data + 1 past the end of the data, and the %s walk reads adjacent<br /> slab memory until it meets a NUL. The same happens when the payload is<br /> not NUL-terminated within skb-&gt;len. The out-of-bounds bytes end up in<br /> the kernel log and the firmware-info debugfs file.<br /> <br /> Print the revision string with a bounded "%.*s" limited to skb-&gt;len - 1<br /> instead. This keeps the string readable for well-behaved devices while<br /> never reading past the received data, and does not fail setup, so a<br /> device returning a short or unterminated response keeps working.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qualcomm: rmnet: validate MAP frame length before ingress parsing<br /> <br /> When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes<br /> the skb straight to __rmnet_map_ingress_handler(), skipping the length<br /> validation that rmnet_map_deaggregate() performs on the aggregated path.<br /> The parser then dereferences the MAP header and csum header/trailer based on<br /> the on-wire pkt_len without checking skb-&gt;len, so a short frame is read out<br /> of bounds:<br /> <br /> BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet<br /> Read of size 1 at addr ffff88801118ed00 by task exploit/147<br /> Call Trace:<br /> ...<br /> rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413)<br /> __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96)<br /> rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129)<br /> __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089)<br /> netif_receive_skb (net/core/dev.c:6460)<br /> tun_get_user (drivers/net/tun.c:1955)<br /> tun_chr_write_iter (drivers/net/tun.c:2001)<br /> vfs_write (fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> ...<br /> <br /> Factor that validation out of rmnet_map_deaggregate() into<br /> rmnet_map_validate_packet_len() and run it on the no-aggregation path too.<br /> The MAP header is bounds-checked first, since this path can receive a frame<br /> shorter than the header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().<br /> <br /> fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg-&gt;dev) and<br /> dereferences idev-&gt;cnf.mtu6 without a NULL check. addrconf_ifdown()<br /> clears dev-&gt;ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has<br /> released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and<br /> oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(),<br /> but this re-fetch is unguarded; nexthop-backed routes survive<br /> addrconf_ifdown()&amp;#39;s flush, so the walk still reaches it after ip6_ptr is<br /> nulled.<br /> <br /> Return 0 when idev is NULL, matching rt6_mtu_change_route() and the<br /> fib6_mtu() fix in commit 5ad509c1fdad ("ipv6: Fix null-ptr-deref in<br /> fib6_mtu().").<br /> <br /> Oops: general protection fault, ... KASAN: null-ptr-deref in range<br /> [0x00000000000002a8-0x00000000000002af]<br /> RIP: 0010:fib6_nh_mtu_change+0x203/0x990<br /> rt6_mtu_change_route+0x141/0x1d0<br /> __fib6_clean_all+0xd0/0x160<br /> rt6_mtu_change+0xb4/0x100<br /> ndisc_router_discovery+0x24b5/0x2cb0<br /> icmpv6_rcv+0x12e9/0x1710<br /> ipv6_rcv+0x39b/0x410

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: eir: Fix stack OOB write when prepending the Flags AD<br /> <br /> eir_create_adv_data() builds the advertising data into a fixed-size<br /> buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags"<br /> AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies<br /> the per-instance data without checking that it still fits:<br /> <br /> memcpy(ptr, adv-&gt;adv_data, adv-&gt;adv_data_len);<br /> <br /> tlv_data_max_len() only reserves those 3 bytes when the user-supplied<br /> flags carry a managed-flags bit, so an instance added with flags == 0 is<br /> accepted with adv_data_len up to the full buffer. At advertise time the<br /> flags are still prepended, and the memcpy() writes 3 + adv_data_len<br /> bytes into the size-byte buffer:<br /> <br /> BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)<br /> Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65<br /> Workqueue: hci0 hci_cmd_sync_work<br /> __asan_memcpy (mm/kasan/shadow.c:106)<br /> eir_create_adv_data (net/bluetooth/eir.c:301)<br /> hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)<br /> hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)<br /> hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)<br /> This frame has 1 object:<br /> [32, 64) &amp;#39;cp&amp;#39;<br /> <br /> The "Flags" structure is added by the kernel, not requested by<br /> userspace, so only prepend it when it fits together with the instance<br /> advertising data; when there is no room for both, drop the flags rather<br /> than the user-provided data.<br /> <br /> Reachable by a local user with CAP_NET_ADMIN owning an LE-only<br /> controller on the legacy advertising path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()<br /> <br /> genelink_rx_fixup() splits an aggregated RX frame into its individual<br /> packets, using a per-packet length taken from device-supplied data. That<br /> length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared<br /> against how many bytes were actually received.<br /> <br /> A malicious GeneLink (GL620A) device can therefore send a short URB whose<br /> header claims packet_count &gt; 1 and a first packet of up to 1514 bytes.<br /> <br /> skb_put_data(gl_skb, packet-&gt;packet_data, size);<br /> <br /> then copies past the end of the receive buffer and hands the adjacent slab<br /> contents up the network stack, an out-of-bounds read that leaks kernel heap.<br /> No privilege is required: the path runs in the usbnet RX softirq as soon as<br /> the interface is up.<br /> <br /> BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)<br /> Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14<br /> Call Trace:<br /> ...<br /> __asan_memcpy (mm/kasan/shadow.c:105)<br /> genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)<br /> usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)<br /> process_one_work (kernel/workqueue.c:3322)<br /> bh_worker (kernel/workqueue.c:3405)<br /> tasklet_action (kernel/softirq.c:965)<br /> handle_softirqs (kernel/softirq.c:622)<br /> run_ksoftirqd (kernel/softirq.c:1076)<br /> ...<br /> <br /> skb_pull() already verifies that the requested length fits the buffer and<br /> returns NULL otherwise. Move it ahead of the copy and check its result, so<br /> a packet that overruns the received data is rejected before it is read.<br /> Well-formed frames, whose packets are fully present, are unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket<br /> <br /> smc_cdc_rx_handler() looks up the connection by token under the link<br /> group&amp;#39;s conns_lock, drops the lock, and then dereferences conn and the<br /> smc_sock derived from it, ending in sock_hold(&amp;smc-&gt;sk) inside<br /> smc_cdc_msg_recv(). No reference is held across the lock release.<br /> <br /> The only reference pinning the socket while the connection is<br /> discoverable in the link group is taken in smc_lgr_register_conn()<br /> (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both<br /> under conns_lock. Once the handler drops conns_lock, a concurrent<br /> close() -&gt; smc_release() -&gt; smc_conn_free() -&gt; smc_lgr_unregister_conn()<br /> can drop that reference and free the smc_sock, so the handler&amp;#39;s later<br /> sock_hold() runs on freed memory:<br /> <br /> WARNING: lib/refcount.c:25 at refcount_warn_saturate<br /> Workqueue: rxe_wq do_work<br /> refcount_warn_saturate (lib/refcount.c:25)<br /> smc_cdc_msg_recv (net/smc/smc_cdc.c:430)<br /> smc_cdc_rx_handler (net/smc/smc_cdc.c:502)<br /> smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445)<br /> tasklet_action_common (kernel/softirq.c:938)<br /> handle_softirqs (kernel/softirq.c:622)<br /> Kernel panic - not syncing: panic_on_warn set<br /> <br /> Only SMC-R is affected. The SMC-D receive tasklet is stopped by<br /> tasklet_kill(&amp;conn-&gt;rx_tsklet) in smc_conn_free() before the connection<br /> is unregistered, so it cannot run concurrently with the free.<br /> <br /> Take the socket reference while still holding conns_lock, so the<br /> registration reference can no longer be the last one, and drop it once<br /> the handler is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ndisc: fix NULL deref in accept_untracked_na()<br /> <br /> accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)<br /> and dereferences idev-&gt;cnf.accept_untracked_na without a NULL check,<br /> even though its only caller ndisc_recv_na() already fetched and<br /> NULL-checked idev for the same device.<br /> <br /> Both reads of dev-&gt;ip6_ptr run in the same RCU read-side critical<br /> section, but a concurrent addrconf_ifdown() can clear dev-&gt;ip6_ptr<br /> between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown()<br /> without the synchronize_net() that orders the unregister path, so the<br /> re-fetch returns NULL and oopses:<br /> <br /> BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> Read of size 4 at addr 0000000000000364<br /> Call Trace:<br /> <br /> ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> icmpv6_rcv (net/ipv6/icmp.c:1193)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)<br /> ip6_input_finish (net/ipv6/ip6_input.c:534)<br /> ip6_input (net/ipv6/ip6_input.c:545)<br /> ip6_mc_input (net/ipv6/ip6_input.c:635)<br /> ipv6_rcv (net/ipv6/ip6_input.c:351)<br /> <br /> <br /> It is reachable by an unprivileged user via a network namespace.<br /> <br /> Pass the caller&amp;#39;s already validated idev instead of re-fetching it; the<br /> idev stays alive for the whole RCU critical section, so it is safe even<br /> after dev-&gt;ip6_ptr has been cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix use-after-free of the discoverer in tipc_disc_rcv()<br /> <br /> bearer_disable() frees b-&gt;disc with tipc_disc_delete()&amp;#39;s plain kfree(),<br /> but tipc_disc_rcv() still dereferences b-&gt;disc in RX softirq under<br /> rcu_read_lock() (tipc_udp_recv -&gt; tipc_rcv -&gt; tipc_disc_rcv).<br /> <br /> L2 bearers are safe thanks to the synchronize_net() in<br /> tipc_disable_l2_media(), but the UDP bearer defers that call to the<br /> cleanup_bearer() workqueue, so the discoverer is freed with no grace<br /> period:<br /> <br /> BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149)<br /> Read of size 8 at addr ffff88802348b728 by task poc_tipc/184<br /> <br /> tipc_disc_rcv (net/tipc/discover.c:149)<br /> tipc_rcv (net/tipc/node.c:2126)<br /> tipc_udp_recv (net/tipc/udp_media.c:391)<br /> udp_rcv (net/ipv4/udp.c:2643)<br /> ip_local_deliver_finish (net/ipv4/ip_input.c:241)<br /> <br /> Freed by task 181:<br /> kfree (mm/slub.c:6565)<br /> bearer_disable (net/tipc/bearer.c:418)<br /> tipc_nl_bearer_disable (net/tipc/bearer.c:1001)<br /> <br /> The bearer is freed with kfree_rcu(); free the discoverer the same way.<br /> Add an rcu_head to struct tipc_discoverer and free it and its skb from an<br /> RCU callback.<br /> <br /> Because the RCU callback (tipc_disc_free_rcu) lives in module text, a<br /> call_rcu() that is still pending when the tipc module is unloaded would<br /> invoke a freed function. Add an rcu_barrier() to tipc_exit() after the<br /> bearer subsystem has been torn down, so all pending discoverer callbacks<br /> have run before the module text goes away.<br /> <br /> Reachable from an unprivileged user namespace: the TIPCv2 genl family is<br /> netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC<br /> and CONFIG_TIPC_MEDIA_UDP.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents<br /> <br /> pefile_digest_pe_contents() computes the trailing-data hash length as<br /> pelen - (hashed_bytes + certs_size). A crafted PE can make the addition<br /> exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB.<br /> This is passed to crypto_shash_update() which reads out of bounds and<br /> panics on unmapped vmalloc guard pages.<br /> <br /> BUG: unable to handle page fault for address: ffffc900038d8000<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152)<br /> Call Trace:<br /> <br /> __sha256_update (lib/crypto/sha256.c:208)<br /> crypto_sha256_update (crypto/sha256.c:142)<br /> verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436)<br /> kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151)<br /> __do_sys_kexec_file_load (kernel/kexec_file.c:406)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Validate that the addition does not overflow and the result does not<br /> exceed pelen before the subtraction. Return -ELIBBAD on failure.