Linux

Buffer overflow in Linux kernel Xen hypervisor interface allows local authenticated users to achieve arbitrary code execution with high privilege escalation impact. The vulnerability stems from improper handling of non-NUL-terminated build ID data from HYPERVISOR_xen_version(XENVER_build_id) in drivers/xen/sys-hypervisor.c, where sprintf reads past buffer boundaries seeking a NUL terminator. Affects Linux kernel versions from 5.10 through 7.0 series when running as Xen domain. Vendor-released patches available across all affected stable branches (5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.26, 7.0.3). EPSS score of 0.08% (23rd percentile) indicates low probability of mass exploitation despite high CVSS 7.8, reflecting specialized Xen-only attack surface. No public exploit identified at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: igb: remove napi_synchronize() in igb_down() When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9), the XSK buffer pool is destroyed but NAPI polling continues. igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing napi_complete_done() from clearing NAPI_STATE_SCHED. igb_down() calls napi_synchronize() before napi_disable() for each queue vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear, which never happens. igb_down() blocks indefinitely, the TX watchdog fires, and the TX queue remains permanently stalled. napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE. After a full-budget poll, __napi_poll() checks napi_disable_pending(). If set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop that napi_synchronize() cannot. napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible panic caused by Rx traffic arrival while interface is down"). napi_disable() provides stronger guarantees: it prevents further scheduling and waits for any active poll to exit. Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a preceding napi_synchronize() in their down paths. Remove redundant napi_synchronize() call and reorder napi_disable() before igb_set_queue_napi() so the queue-to-NAPI mapping is only cleared after polling has fully stopped.

Buffer overflow in TH1520 AON firmware protocol driver allows local authenticated attackers with low privileges to execute arbitrary code and gain elevated system access. The vulnerability stems from unsafe pointer arithmetic when accessing the 'mode' field through the 'resource' pointer with unchecked offsets in the T-HEAD firmware driver. Patches available across stable kernel branches (6.18.23, 6.19.13, 7.0) with low EPSS score (0.02%) indicating minimal observed exploitation attempts, though CVSS 7.8 reflects high impact if exploited on affected T-HEAD TH1520 systems.

Denial of service in the Linux kernel EDAC (Error Detection and Correction) subsystem due to improper initialization ordering in edac_mc_alloc(). When memory allocation fails during EDAC memory controller initialization, the error path calls put_device() before device_initialize() is executed, triggering a null pointer dereference in kobject_put() that causes a kernel panic or system crash. This affects Linux systems with EDAC support enabled across multiple kernel versions from 5.19 through 7.0.

Use-after-free in Linux kernel driver core allows local authenticated users to execute arbitrary code, escalate privileges, or crash the system via race condition in device-driver binding operations. The vulnerability stems from inconsistent locking in driver_match_device() function calls, specifically affecting driver_override functionality where device_lock was not held during bind_store() and __driver_attach() operations. EPSS probability is very low (0.02%, 5th percentile), indicating minimal real-world exploitation observed. No active exploitation confirmed - no CISA KEV listing identified. Patch available in kernel 7.0+ and backport commit dc23806a7c47.

Denial of service in Linux kernel GPIO OMAP driver allows local authenticated users to crash the system via a deadlock condition triggered by improper driver registration from probe() callback. The vulnerability stems from registering the omap_mpuio_driver within omap_gpio_probe(), which violates driver core locking rules and creates a potential deadlock when device_lock enforcement was strengthened in commit dc23806a7c47. EPSS score of 0.03% reflects low exploitation probability despite availability of patched kernel versions.

In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint

In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.

In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.

In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.

In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.

In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.

In the Linux kernel, the following vulnerability has been resolved: openvswitch: defer tunnel netdev_put to RCU release ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev. Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let vport_netdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.

In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_netem: fix out-of-bounds access in packet corruption In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0. Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access. Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.

In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.

In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.

Integer overflow in OP-TEE OS RSA signature encoding crashes the Trusted Execution Environment on platforms with RSA hardware acceleration. Affects versions 3.8.0 through 4.10 when attackers supply cryptographic operations with deliberately undersized RSA moduli, causing memset() to overwrite memory until the TEE crashes. This denial-of-service attack requires no authentication and can be triggered remotely (CVSS AV:N/PR:N), completely disabling the secure-world environment that protects cryptographic keys, biometric data, and DRM operations on affected Arm TrustZone systems. EPSS data not available; no active exploitation confirmed at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.

In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.

In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.

In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref() After commit 1618aa3c2e01 ("btrfs: simplify return variables in lookup_extent_data_ref()"), the err and ret variables were merged into a single ret variable. However, when btrfs_next_leaf() returns 0 (success), ret is overwritten from -ENOENT to 0. If the first key in the next leaf does not match (different objectid or type), the function returns 0 instead of -ENOENT, making the caller believe the lookup succeeded when it did not. This can lead to operations on the wrong extent tree item, potentially causing extent tree corruption. Fix this by returning -ENOENT directly when the key does not match, instead of relying on the ret variable.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0

In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().

In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.

In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.

In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.

Use-after-free in Linux kernel batman-adv (B.A.T.M.A.N. Advanced mesh networking) allows remote network attackers to trigger memory corruption and potentially execute arbitrary code. The batadv_bla_add_claim() function can prematurely drop a gateway reference while readers still access the pointer, causing netlink dump and claim-check paths to dereference freed memory. Despite CVSS 9.8 critical rating, exploitation probability is low (EPSS 2%, 7th percentile), no active exploitation confirmed, and patches available across kernel stable branches 6.1.169, 6.6.135, 6.12.82, 6.18.23, 6.19.13, and mainline 7.0.

Local privilege escalation in the Linux kernel's i915 graphics driver allows authenticated users to trigger a use-after-free condition via a race between the heartbeat worker and intel_engine_park_heartbeat() function when releasing engine heartbeat requests. The vulnerability stems from a non-atomic pointer read-and-clear operation that permits double-free of the same request object, causing refcount underflow and potential arbitrary code execution with elevated privileges. Patches are available across multiple stable kernel branches (5.15.203, 6.1.169, 6.6.135, 6.12.82, 6.18.23, 6.19.13, 7.0). EPSS exploitation probability is low (0.02%, 7th percentile), and no public exploit or active exploitation has been identified at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.

In the Linux kernel, the following vulnerability has been resolved: mm/vma: fix memory leak in __mmap_region() commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare swaps the file") handled the success path by skipping get_file() via file_doesnt_need_get, but missed the error path. When /dev/zero is mmap'd with MAP_SHARED, mmap_zero_prepare() calls shmem_zero_setup_desc() which allocates a new shmem file to back the mapping. If __mmap_new_vma() subsequently fails, this replacement file is never fput()'d - the original is released by ksys_mmap_pgoff(), but nobody releases the new one. Add fput() for the swapped file in the error path. Reproducible with fault injection. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x164/0x1f0 should_fail_ex+0x525/0x650 should_failslab+0xdf/0x140 kmem_cache_alloc_noprof+0x78/0x630 vm_area_alloc+0x24/0x160 __mmap_region+0xf6b/0x2660 mmap_region+0x2eb/0x3a0 do_mmap+0xc79/0x1240 vm_mmap_pgoff+0x252/0x4c0 ksys_mmap_pgoff+0xf8/0x120 __x64_sys_mmap+0x12a/0x190 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881118aca80 (size 360): comm "syz.7.14", pid 366, jiffies 4294913255 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M..... backtrace (crc db0f53bc): kmem_cache_alloc_noprof+0x3ab/0x630 alloc_empty_file+0x5a/0x1e0 alloc_file_pseudo+0x135/0x220 __shmem_file_setup+0x274/0x420 shmem_zero_setup_desc+0x9c/0x170 mmap_zero_prepare+0x123/0x140 __mmap_region+0xdda/0x2660 mmap_region+0x2eb/0x3a0 do_mmap+0xc79/0x1240 vm_mmap_pgoff+0x252/0x4c0 ksys_mmap_pgoff+0xf8/0x120 __x64_sys_mmap+0x12a/0x190 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e Found by syzkaller.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow the kdamond is stopped before the damon_call(). It could happen, for example, when te damon context was made for monitroing of a virtual address processes, and the process is terminated immediately, before the damon_call() invocation. In the case, the dyanmically allocated repeat_call_control is not deallocated and leaked. Fix the leak by deallocating the repeat_call_control under the damon_call() failure. This issue is discovered by sashiko [1].

In the Linux kernel, the following vulnerability has been resolved: mm/damon/stat: deallocate damon_call() failure leaking damon_ctx damon_stat_start() always allocates the module's damon_ctx object (damon_stat_context). Meanwhile, if damon_call() in the function fails, the damon_ctx object is not deallocated. Hence, if the damon_call() is failed, and the user writes Y to “enabled” again, the previously allocated damon_ctx object is leaked. This cannot simply be fixed by deallocating the damon_ctx object when damon_call() fails. That's because damon_call() failure doesn't guarantee the kdamond main function, which accesses the damon_ctx object, is completely finished. In other words, if damon_stat_start() deallocates the damon_ctx object after damon_call() failure, the not-yet-terminated kdamond could access the freed memory (use-after-free). Fix the leak while avoiding the use-after-free by keeping returning damon_stat_start() without deallocating the damon_ctx object after damon_call() failure, but deallocating it when the function is invoked again and the kdamond is completely terminated. If the kdamond is not yet terminated, simply return -EAGAIN, as the kdamond will soon be terminated. The issue was discovered [1] by sashiko.

In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on disconnect The vub300 driver maintains an explicit reference count for the controller and its driver data and the last reference can in theory be dropped after the driver has been unbound. This specifically means that the controller allocation must not be device managed as that can lead to use-after-free. Note that the lifetime is currently also incorrectly tied the parent USB device rather than interface, which can lead to memory leaks if the driver is unbound without its device being physically disconnected (e.g. on probe deferral). Fix both issues by reverting to non-managed allocation of the controller.

Integer underflow in Linux kernel stmmac network driver allows kernel memory disclosure and potential corruption via crafted network packets. The flaw occurs in chain mode jumbo frame handling when packets have small linear data but large total length from page fragments, causing buffer offset calculations to wrap to ~0xFFFFxxxx. This triggers massive loop iterations that DMA-map arbitrary kernel memory to the network hardware. On typical stmmac deployments (IOMMU-less embedded SoCs), attackers can remotely read kernel memory contents and potentially corrupt memory through hardware DMA operations. EPSS exploitation probability is low (0.02%) with no confirmed active exploitation, but CVSS 9.8 reflects the theoretical remote unauthenticated attack surface. Vendor patches available across all supported stable kernel branches (5.10.253, 5.15.203, 6.1.169, 6.6.135, 6.12.82, 6.18.23, 6.19.13, 7.0).

Race condition in Linux kernel memory management allows local attackers with low privileges to corrupt kernel page state, potentially achieving high-impact denial of service, data corruption, or privilege escalation. The vulnerability affects kernel versions 6.6.x through 7.0-rc3, with patches confirmed released for stable branches 6.6.135, 6.12.82, 6.18.23, 6.19.13, and mainline 7.0. EPSS exploitation probability is low (0.02%, 5th percentile), and no public exploit code or active exploitation has been identified at time of analysis. The CVSS vector (AV:L/AC:L/PR:L/UI:N) indicates local access with low attack complexity, while the specific race condition requires precise timing between file mapping and inode size modification operations.

In the Linux kernel, the following vulnerability has been resolved: idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling Switch from using the completion's raw spinlock to a local lock in the idpf_vc_xn struct. The conversion is safe because complete/_all() are called outside the lock and there is no reason to share the completion lock in the current logic. This avoids invalid wait context reported by the kernel due to the async handler taking BH spinlock: [ 805.726977] ============================= [ 805.726991] [ BUG: Invalid wait context ] [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE [ 805.727026] ----------------------------- [ 805.727038] kworker/u261:0/572 is trying to lock: [ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727099] other info that might help us debug this: [ 805.727111] context-{5:5} [ 805.727119] 3 locks held by kworker/u261:0/572: [ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730 [ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730 [ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf] [ 805.727218] stack backtrace: ... [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf] [ 805.727247] Call Trace: [ 805.727249] <TASK> [ 805.727251] dump_stack_lvl+0x77/0xb0 [ 805.727259] __lock_acquire+0xb3b/0x2290 [ 805.727268] ? __irq_work_queue_local+0x59/0x130 [ 805.727275] lock_acquire+0xc6/0x2f0 [ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727284] ? _printk+0x5b/0x80 [ 805.727290] _raw_spin_lock_bh+0x38/0x50 [ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf] [ 805.727317] process_one_work+0x226/0x730 [ 805.727322] worker_thread+0x19e/0x340 [ 805.727325] ? __pfx_worker_thread+0x10/0x10 [ 805.727328] kthread+0xf4/0x130 [ 805.727333] ? __pfx_kthread+0x10/0x10 [ 805.727336] ret_from_fork+0x32c/0x410 [ 805.727345] ? __pfx_kthread+0x10/0x10 [ 805.727347] ret_from_fork_asm+0x1a/0x30 [ 805.727354] </TASK>

In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure.

In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page pool leak in error paths lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error paths.

Use-after-free in Linux kernel's lan966x network driver allows local authenticated attackers to achieve arbitrary code execution with high impact to confidentiality, integrity, and availability. The flaw occurs in lan966x_fdma_reload() when RX buffer allocation fails - freed pages remain referenced by active DMA descriptors, causing hardware to write into memory now controlled by other kernel subsystems. Vendor patches available for stable branches 6.12.82, 6.18.23, 6.19.13, and mainline 7.0. EPSS score of 0.02% (5th percentile) indicates low probability of widespread exploitation. No CISA KEV listing or public exploit identified at time of analysis, but successful exploitation grants kernel-level privileges to local attackers.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key parsing memleak In rxrpc_preparse_xdr_yfs_rxgk(), the memory attached to token->rxgk can be leaked in a few error paths after it's allocated. Fix this by freeing it in the "reject_token:" case.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.

Heap buffer overflow in Linux kernel rxrpc subsystem allows local authenticated users to trigger memory corruption via crafted RxGK tokens. Exploitable through unprivileged add_key() system call when raw key/ticket lengths >= 0xfffffffd cause integer wraparound in round_up(), bypassing bounds checks while memcpy() copies up to 4 GiB into zero-sized heap allocation. Vendor patches available for stable branches 6.18.23, 6.19.13, and mainline 7.0. EPSS score of 0.02% (4th percentile) indicates low observed exploitation probability despite local privilege escalation potential with CVSS 7.8.

Linux kernel rxrpc subsystem allows remote denial of service via malformed RESP challenge packets due to incorrect serial number comparison logic. The rxrpc_post_response() function compares challenge serial numbers from the wrong packet structure, causing response queue corruption that can crash the kernel networking stack. This affects Linux kernel versions containing commit 5800b1cf3fd8 through the 6.16-6.19 and 7.0 series. Patches are available from kernel.org for affected stable branches. EPSS exploitation probability is very low (0.02%, 4th percentile) and no public exploits or active exploitation have been identified, suggesting limited real-world risk despite the network-accessible attack vector.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference count leak from call->key When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ After the patch, the invalidated key is removed when the code exits: $ cat /proc/keys | grep afs@54321 $

Null pointer dereference in Linux kernel rxrpc subsystem allows remote network attackers to crash the system by sending malformed packets to a client-side connection after a call has been torn down. The flaw affects Linux kernel versions 6.2 onward where the rxrpc client code unconditionally releases a call reference that was never acquired, converting a protocol error into a kernel panic. Vendor patches are available across stable branches (6.6.135, 6.12.82, 6.18.23, 6.19.13, 7.0). EPSS exploitation probability is low (0.02%, 5th percentile) and no public exploit has been identified at time of analysis.

Unauthenticated remote attackers can exploit a cryptographic validation bypass in the Linux kernel's RxRPC rxkad authentication handler to potentially execute arbitrary code or cause denial of service. The rxkad_decrypt_ticket() function fails to verify that RXKAD response ticket decryption succeeded before parsing the buffer contents, allowing malformed RESPONSE packets with non-block-aligned ticket lengths to drive the ticket parser with attacker-controlled ciphertext bytes. Despite the critical 9.8 CVSS score indicating network-exploitable attack with high impact across confidentiality, integrity, and availability, EPSS exploitation probability is low (0.02%, 5th percentile) and no active exploitation or public POC has been identified. Patches are available across multiple stable kernel versions (6.6.135, 6.12.82, 6.18.23, 6.19.13, 7.0).

Out-of-bounds read in Linux kernel's rxrpc rxgk authentication handler allows remote unauthenticated attackers to trigger information disclosure and denial of service via malformed RESPONSE authenticator packets. The vulnerability stems from incorrect pointer arithmetic in rxgk_verify_authenticator() that inflates the parser boundary check by a factor of four, allowing reads beyond kmalloc() buffer boundaries. Vendor patches available for kernel versions 6.18.23, 6.19.13, and 7.0. EPSS score of 0.02% (4th percentile) suggests low observed exploitation probability despite network attack vector, though KASAN reports confirm reproducibility.

Remote denial of service in Linux kernel rxrpc subsystem allows unauthenticated network attackers to trigger kernel crash via malformed rxgk RESPONSE packets. An inverted length check in rxgk_verify_response() accepts oversized authenticators, causing skb_to_sgvec() to hit BUG_ON() and panic the kernel. EPSS exploitation probability is very low (0.02%, 4th percentile), no active exploitation confirmed, and patches are available across stable kernel branches 6.18.23, 6.19.13, and 7.0.

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

Integer overflow in Linux kernel's rxrpc rxgk_verify_response() function allows remote unauthenticated attackers to bypass length validation checks and potentially achieve arbitrary code execution. The vulnerability exists in the rxrpc protocol implementation where token_len rounding occurs before validation, enabling buffer overflow conditions. With CVSS 9.8 (critical severity) and network attack vector requiring no authentication, this represents a significant exposure despite low EPSS score (0.02%, 4th percentile), suggesting limited real-world exploitation observed to date. Vendor patches are available across multiple stable kernel versions (6.18.23, 6.19.13, 7.0).

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

Buffer overread in Linux kernel's rxgk_do_verify_authenticator() function allows remote unauthenticated attackers to trigger information disclosure and high-availability denial of service through network-accessible RxGK authentication handling. The vulnerability stems from improper buffer size validation before nonce verification in the RxRPC subsystem. Patches are available from the Linux kernel stable tree (versions 6.19.13, 6.18.23, and 7.0). EPSS score of 0.02% (4th percentile) indicates very low observed exploitation probability, and no active exploitation or public POC has been identified. Despite the high CVSS base score of 8.2, real-world risk appears limited to environments using RxRPC with RxGK authentication.

Buffer overflow in Linux kernel's AF_RXRPC procfs address formatting allows local authenticated users to corrupt memory and potentially escalate privileges. The vulnerability affects rxrpc proc handlers that write IPv6 socket addresses into 50-byte stack buffers, but ISATAP-format IPv6 addresses with ports can require 51 bytes, causing single-byte overflow. EPSS exploitation probability is low (0.02%, 4th percentile), and patches are available from kernel.org for versions 6.18.23, 6.19.13, and mainline 7.0. No active exploitation confirmed (not in CISA KEV), and CVSS 7.8 reflects local-only attack vector requiring authenticated access.

Use-after-free in Linux kernel NFC LLCP implementation allows adjacent-network attackers to execute arbitrary code with kernel privileges. The flaw occurs when socket state is LLCP_CLOSED in nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), where missing return statements cause double release_sock() and refcount underflow, leading to memory corruption. Vendor-released patches available for stable kernels 6.12.83, 6.18.24, 6.19.14, and 7.0.1. EPSS score of 0.02% (5th percentile) indicates low observed exploitation probability, and no active exploitation or public POC confirmed at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.

Buffer overflow in Linux kernel's s3c24xx I2C driver allows local authenticated attackers to achieve arbitrary code execution with high privileges through malformed SMBUS block read messages. The driver fails to validate message length against I2C_SMBUS_BLOCK_MAX before processing, enabling out-of-bounds memory access. Vendor patches available for kernel versions 6.12.83, 6.18.24, 6.19.14, and 7.0.1. EPSS score of 0.02% suggests low observed exploitation activity, with no CISA KEV listing indicating targeted rather than widespread attacks. Attack requires local access and low-level user privileges (CVSS AV:L/PR:L), limiting practical exploitability compared to the high CVSS 7.8 base score.

Uninitialized memory read in Linux kernel's rtl8723bs Wi-Fi driver allows adjacent network attackers to cause denial of service or potentially corrupt integrity through malformed BIP (Broadcast/Multicast Integrity Protocol) frames. The vulnerability affects the staging rtl8723bs driver where only 6 bytes are copied into an 8-byte variable during BIP verification, leaving 2 bytes uninitialized. Patches available across multiple stable kernel versions (6.12.83, 6.18.24, 6.19.14, 7.0.1). EPSS score of 0.02% (5th percentile) indicates low observed exploitation probability. Not listed in CISA KEV, and no public exploit identified at time of analysis.

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

Shift-out-of-bounds vulnerability in Linux kernel HID core driver allows local authenticated attackers to cause denial of service via crafted HID device report descriptors with oversized fields that trigger undefined bit-shift operations in the s32ton() function. A malicious or malfunctioning HID device can supply a report_size value up to 256, causing shifts on 32-bit integers with exponents exceeding safe limits, crashing the kernel or triggering undefined behavior. CVSS 5.5 reflects local-only attack vector with low complexity and requirement for user/driver privileges to process HID output reports.

Denial of service via skb_shared_info->frags[] buffer overflow in the CDC Phonet USB driver allows local attackers with USB device access to crash the kernel by sending unbounded sequences of full-page bulk transfers. A malicious or compromised USB modem device can trigger this overflow without authentication or user interaction. The vulnerability has a low EPSS score (0.02%) despite moderate CVSS (5.5), indicating exploitation requires specific local USB hardware control.

Heap buffer overflow in Linux kernel NFC-A digital target driver allows adjacent-network attackers to corrupt memory and potentially execute code. A malicious NFC peer device can trigger unbounded cascade loops during anti-collision protocol, writing beyond the 10-byte nfcid1 buffer with each iteration. EPSS score of 0.02% (5th percentile) indicates low likelihood of mass exploitation, but the adjacent attack vector (AV:A) limits exposure to proximity-based attacks. Vendor patches available across multiple stable kernel branches (6.12.83, 6.18.24, 6.19.14, 7.0.1). No active exploitation confirmed (not in CISA KEV); no public exploit identified at time of analysis.

Null pointer dereference in Linux kernel bnge driver occurs when auxiliary_device_add() fails and the error handling path omits a return statement after auxiliary_device_uninit(), causing subsequent code to dereference a freed and nullified auxr_dev pointer. Local users with limited privileges can trigger kernel panic (denial of service) by inducing auxiliary device initialization failure. EPSS score of 0.02% reflects low real-world exploitation probability despite availability of vendor patches in stable branches 6.19.14 and 7.0.1.

Null pointer dereference in the ALSA TASCAM US-144MKII USB audio driver allows local attackers with physical access to a malicious USB device to cause a kernel panic and denial of service. The vulnerability exists because the driver fails to validate that USB interface 0 exists before dereferencing it, and attackers can craft a malicious USB configuration that includes only interface 1, triggering the crash when the device is connected.

Denial of service via out-of-bounds string lookup in Linux kernel ALSA fireworks driver allows local authenticated users to crash the system by supplying an invalid status value from a firewire device. The vulnerability stems from insufficient bounds checking on a 32-bit status field before array indexing into a 17-entry string table, enabling memory access violations when the device reports unexpected values including EFR_STATUS_INCOMPLETE (0x80000000).

Divide-by-zero denial of service in Linux kernel framebuffer driver tdfxfb allows local authenticated users to crash the system by issuing a malformed FBIOPUT_VSCREENINFO ioctl with zero pixclock value. The vulnerability affects the framebuffer video mode setting functionality when pixclock is used directly in division operations without validation, triggering a kernel panic.

Integer underflow in the Linux kernel's USB NCM gadget driver allows a malicious USB host to bypass buffer boundary checks and copy adjacent kernel memory into network packet buffers. The vulnerability exists in ncm_unwrap_ntb() where block_len values smaller than the NDP size cause unsigned integer underflow in bounds validation, enabling out-of-bounds memory read and potential information disclosure. Affected versions prior to Linux 6.12.83, 6.18.24, 6.19.14, and 7.0.1 require patching; exploitation requires local USB device attachment or administrative USB gadget configuration.

Memory corruption via skb fragment array overflow in the USB Phonet gadget driver allows local attackers with device-level USB host capabilities to cause denial of service. The vulnerability exists in pn_rx_complete() which fails to enforce the MAX_SKB_FRAGS limit when processing unbounded full-page OUT transfers, causing heap memory corruption adjacent to the skb_shared_info structure. A malicious or misconfigured USB host sending continuous PAGE_SIZE byte transfers triggers the flaw in gadgets exposing the Phonet function, confirmed fixed in Linux 6.12.83, 6.18.24, 6.19.14, and 7.0.1.

Null pointer dereference in the Renesas USB3 gadget driver allows local authenticated attackers to trigger a denial of service by sending crafted USB standard requests with invalid endpoint indices that bypass validation in GET_STATUS and SET/CLEAR_FEATURE handlers. The vulnerability affects multiple stable kernel versions and requires local access with user-level privileges, resulting in potential system crash or service disruption.

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix off-by-8 bounds check in check_wsl_eas() The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA name and value, but ea_data sits at offset sizeof(struct smb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp() later reads ea->ea_data[0..nlen-1] and the value bytes follow at ea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1 + vlen. Isn't pointer math fun? The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the 8-byte header is in bounds, but since the last EA is placed within 8 bytes of the end of the response, the name and value bytes are read past the end of iov. Fix this mess all up by using ea->ea_data as the base for the bounds check. An "untrusted" server can use this to leak up to 8 bytes of kernel heap into the EA name comparison and influence which WSL xattr the data is interpreted as.

Out-of-bounds heap read in Linux kernel SMB client allows malicious SMB servers to leak kernel memory to userspace via crafted symlink error responses. When processing STATUS_STOPPED_ON_SYMLINK errors in SMB 3.1.1, inadequate bounds checking in smb2_check_message() and symlink_data() allows server-controlled ErrorDataLength values to trigger reads beyond buffer boundaries. The leaked heap bytes are UTF-16-decoded into the symlink target and exposed through readlink(2) syscalls (confidentiality impact), with potential for denial-of-service through memory corruption (availability impact). CVSS 8.1 (High) requires user interaction. EPSS score is very low at 0.02% (5th percentile), indicating minimal observed exploitation activity. Patches available in kernel versions 6.18.24, 6.19.14, and 7.0.1.

Information disclosure in Linux kernel's ksmbd SMB server allows remote unauthenticated attackers to leak uninitialized heap memory via malformed SMB2 requests. The vulnerability exists in smb2_get_ea() which fails to validate EaNameLength from client requests before using it in strncmp(), enabling heap content extraction. With EPSS score of 0.02% and no KEV listing, exploitation likelihood remains low despite CVSS 7.5 rating. Patches available across kernel versions 6.12.83, 6.18.24, 6.19.14, and 7.0.1.

Out-of-bounds read in Linux kernel's ksmbd SMB server allows remote unauthenticated attackers to manipulate file permissions by crafting malicious ACE SIDs with insufficient sub-authorities, triggering parse_dacl() to read 4 bytes past the ACL buffer boundary and apply those arbitrary bytes as POSIX file mode bits. EPSS exploitation probability is very low (0.02%, 5th percentile) with no public exploit identified at time of analysis. Vendor-released patches available across stable kernel branches (6.12.83, 6.18.24, 6.19.14, 7.0.1).

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; } so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.

Double-free memory corruption in the Linux kernel SMB client (smbd) allows remote unauthenticated attackers to achieve arbitrary code execution, confidentiality breach, and denial of service. The vulnerability occurs when smbd_free_send_io() is erroneously called twice after smbd_send_batch_flush() operations, creating use-after-free conditions. Exploitation probability is low (EPSS 0.02%, 4th percentile) with no confirmed active exploitation or public POC, but the critical CVSS 9.8 score reflects the severe potential impact if network-accessible SMB client operations are triggered. Vendor patches available for kernel versions 6.18.24, 6.19.14, and 7.0.1.

A double-free vulnerability in the Linux kernel's SMB Direct (RDMA transport) server implementation allows remote unauthenticated attackers to trigger memory corruption with high CVSS 9.8 severity. The flaw occurs when smb_direct_free_sendmsg() is called twice on the same memory region after smb_direct_flush_send_list() moves messages to a batch list. Vendor patches available across kernel versions 6.18.24, 6.19.14, and 7.0.1, with upstream commits confirmed in stable branches. Despite critical CVSS scoring, EPSS probability remains very low at 0.02% (4th percentile) and no active exploitation or public POC identified, suggesting limited real-world targeting of this SMB Direct RDMA feature.

Heap buffer overflow in Linux kernel USB/IP client allows malicious USB/IP servers to execute arbitrary code with kernel privileges via crafted RET_SUBMIT responses. A rogue server can specify a larger number_of_packets value than originally submitted, causing out-of-bounds writes when processing isochronous USB transfers. Patched in kernel versions 6.12.83, 6.18.24, 6.19.14, and 7.0.1. EPSS score of 0.02% (5th percentile) suggests low probability of widespread exploitation despite CVSS 9.8 criticality, indicating this is primarily a risk in environments using USB/IP with untrusted servers rather than a general internet-facing threat.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: don't call cdev_init while cdev in use When calling unbind, then bind again, cdev_init reinitialized the cdev, even though there may still be references to it. That's the case when the /dev/hidg* device is still opened. This obviously unsafe behavior like oopes. This fixes this by using cdev_alloc to put the cdev on the heap. That way, we can simply allocate a new one in hidg_bind.

In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix device leak on probe failure Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on all probe errors (e.g. when descriptor parsing fails). Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks.