Information Disclosure

Incorrect writeback state management in the Linux kernel's netfs and AFS subsystems allows a local low-privileged user on an AFS-mounted system to cause filesystem availability degradation. When netfs_write_single() or afs_single_writepages() skips a write due to lock contention under asynchronous writeback (WB_SYNC_NONE), the affected inode loses its dirty mark without the write being rescheduled, meaning data may never be flushed to the AFS server. No public exploit has been identified and the EPSS score of 0.17% at the 6th percentile reflects very low exploitation probability; patched versions are confirmed available across multiple stable kernel branches.

Memory leak in the Linux kernel's ath11k WiFi driver (Qualcomm Atheros 802.11ax) allows a local low-privileged user to exhaust kernel memory by triggering error paths in two WMI Wake-on-WLAN (WOW) command functions that fail to free associated socket buffers (skb) on failure. Patched across all active stable kernel branches (5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, and mainline 7.1). No active exploitation has been identified, with EPSS at 0.17% (7th percentile), consistent with a routine driver memory management fix rather than a weaponizable vulnerability.

Reference leak in the Linux kernel's Qualcomm Adreno a6xx GPU driver (drm/msm/adreno) can cause kernel memory reference exhaustion on affected hardware, leading to system instability or a kernel panic. The flaw in a6xx_gpu_init() allows of_parse_phandle() node references to escape release on multiple early error return paths, bypassing the required of_node_put() cleanup. No active exploitation has been identified; EPSS is 0.17% (6th percentile), no KEV listing exists, and impact is limited to availability on hardware-specific Linux deployments.

DMA mapping failures in the Linux kernel's dma-mapping subsystem crash device driver probes on ARM64 systems with SPARSEMEM due to an incorrect pfn_valid() precondition check in dma_map_resource(). On Raspberry Pi 4 and similar ARM64/SPARSEMEM platforms, MMIO registers whose physical addresses share a 128MB sparsemem section with RAM are misidentified as RAM, causing WARN_ON_ONCE to fire and dma_map_resource() to return DMA_MAPPING_ERROR, breaking peripheral initialization (e.g., spi_bcm2835 SPI controller). No public exploit identified at time of analysis; this is a functional kernel regression with local availability impact rather than a remotely exploitable security flaw.

Resource exhaustion in the Linux kernel erofs filesystem driver allows a local low-privileged attacker to leak folio references via error paths in erofs_init_inode_xattrs(), potentially causing kernel memory resource exhaustion or denial of service. Affected systems are those running Linux kernel versions from 5.17 through the fix commits, where erofs filesystems with extended attributes (xattrs) are mounted. No public exploit code exists and the vulnerability is absent from CISA KEV; vendor-released patches are available in stable branches targeting 7.0.11 and 7.1.

Memory leak in the Linux kernel's btmtk (MediaTek Bluetooth USB) driver allows a local low-privileged user to exhaust kernel memory, causing denial of service. The vulnerability affects systems running Linux kernel from commit a1c49c434e15050b5dafe3b6f5cc732d4f02d657 onward, with patches confirmed in stable releases 6.6.142, 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and no active exploitation has been confirmed; an EPSS of 0.18% at the 7th percentile places this firmly in low-priority territory for most organizations.

Permanent battery hardware damage on Uniwell-based laptops can be triggered via the platform/x86/uniwill-laptop kernel driver by enabling the battery charging limit through the 'force' module parameter. Affected hardware is limited to older Uniwell OEM models manufactured around 2020 where the charging limit circuitry is incompatible with the feature and causes irreversible battery degradation. No public exploit exists and EPSS stands at 0.16% (6th percentile), reflecting the narrow hardware and configuration prerequisites; however, the impact is severe and permanent - affected batteries cannot be recovered once damaged.

Kernel memory exhaustion via ksmbd's POSIX-to-DACL ACL conversion causes a reliable denial-of-service against Linux SMB servers. Commit 299f962c0b02 introduced `check_add_overflow()` guards in `set_posix_acl_entries_dacl()` to prevent u16 DACL size wrap-around, but the resulting `break` statements bypass the `kfree(sid)` cleanup calls, leaking one or more `struct smb_sid` kernel heap allocations each time the overflow check fires. EPSS is 0.18% (8th percentile), no KEV listing exists, and no public exploit code has been identified, but the leak is deterministic and repeatable on every DACL request against a file with sufficient POSIX ACL entries, making memory exhaustion straightforward for any attacker with SMB access to the server.

Spurious kernel WARN() triggers in Linux kernel mm/memory.c during process teardown when NVIDIA UVM or HMM-capable GPU drivers are present alongside private file-backed mappings containing migrated anonymous folios. The unmap path incorrectly uses vma_is_anonymous() rather than folio_test_anon() to gate device-private/exclusive page handling, producing false-positive kernel warnings (not panics) during munmap or process exit in affected configurations. No public exploit has been identified at time of analysis; EPSS at 0.17% (7th percentile) reflects the narrow triggering conditions required and the non-weaponizable nature of a spurious WARN().

Stale ARM64 Memory Tagging Extension (MTE) tag exposure in the Linux kernel's huge zero folio allocation path undermines the init_on_free security guarantee on AArch64 systems. When the kernel is booted with init_on_free=1 and a 2MB anonymous mapping triggers the huge zero folio path (mapped as a PMD-special entry), the __GFP_ZEROTAGS flag causes post_alloc_hook() to skip tag memory clearing while content zeroing was already handled at free time - leaving whatever allocation tags were previously set accessible to user space. No public exploit has been identified at time of analysis, and EPSS stands at 0.17% (6th percentile), consistent with the narrow architectural and configuration prerequisites required to trigger the flaw.

Spinlock leak in the Linux kernel's huge page device migration subsystem causes a local denial of service via deadlock. A low-privileged local user who can trigger the `migrate_vma_insert_huge_pmd_page` code path while inducing `check_stable_address_space()` to fail will leave the PMD spinlock permanently held, deadlocking any subsequent thread that attempts to acquire it. No public exploit has been identified and EPSS at 0.17% (7th percentile) reflects negligible real-world exploitation probability; the vulnerability is not in CISA KEV.

Kernel stack address disclosure in the Linux kernel's Bluetooth L2CAP subsystem leaks 8 bytes of kernel virtual address space to a paired Bluetooth peer whenever a local user triggers an L2CAP Enhanced Credit-Based Reconfigure (ECRED) request. The flaw was introduced by commit 1c08108f3014 when DEFINE_RAW_FLEX() converted the on-stack PDU struct but left l2cap_send_cmd() receiving the local pointer's stack storage address and sizeof(pointer) instead of the struct address and struct size. As a result, the ECRED reconfigure feature has been functionally broken for local initiators since that commit, and every reconfigure attempt passively leaks a KASLR-randomized kernel stack address to the Bluetooth peer, potentially aiding ASLR/KASLR bypass. No public exploit is identified at time of analysis, and the EPSS score of 0.18% (7th percentile) reflects low automated exploitation probability.

CPU pinning denial-of-service in the Linux kernel L2TP subsystem allows an unprivileged local user to wedge a host CPU indefinitely by exploiting an RCU list management mismatch in l2tp_session_unhash(). By creating a user network namespace (unshare -Urn) to obtain CAP_NET_ADMIN and then racing L2TP_CMD_SESSION_CREATE, L2TP_CMD_SESSION_DELETE, and L2TP_CMD_SESSION_GET against the same tunnel, an attacker causes a session list walker to enter an infinite loop with BH and preemption disabled - stalling RCU grace periods system-wide and rendering the thread unkillable via SIGKILL. No public exploit has been identified at time of analysis; EPSS at 0.17% (6th percentile) indicates low automated exploitation probability and no CISA KEV listing.

Memory leak in the Linux kernel igc driver's Frame Preemption (FPE) implementation affects systems with Intel I225/I226 Ethernet controllers running kernel versions from commit 5422570c0010bb968738f9256eb2bf83e79b4d63 onward. The function igc_fpe_xmit_smd_frame() allocates a socket buffer for SMD frame transmission but fails to release it when igc_fpe_init_tx_descriptor() returns an error, confirmed by kernel SLAB unreferenced-object traces showing 224-byte skb allocations going unfreed. No public exploit has been identified and EPSS stands at 0.17%, indicating negligible broad exploitation interest; the practical exposure is limited to TSN-capable deployments with FPE explicitly enabled.

KVM arm64 vGIC in the Linux kernel leaks kernel memory when vCPU initialization fails, enabling a local attacker with VM-creation privileges to exhaust host memory and cause denial of service. The defect is a missing cleanup call in the kvm_vgic_vcpu_init() error path: private IRQs allocated prior to a redistributor iodev registration failure are never freed before the failed vCPU structure is released. No public exploit has been identified at time of analysis; an EPSS score of 0.17% (6th percentile) reflects low opportunistic exploitation probability, and the flaw is not listed in CISA KEV.

Out-of-bounds heap read in the Linux kernel's fwctl pds driver allows a local low-privileged user to crash the kernel by submitting an undersized RPC buffer, resulting in a denial of service. Affected kernel versions include Linux 6.15 and all stable trees prior to 6.18.34, 7.0.11, and 7.1, with exploitation requiring the pds_fwctl module loaded and a compatible PDS network adapter present. No public exploit exists and EPSS is 0.17% (7th percentile), placing this as a low-priority stability fix unless deployments expose the fwctl device node to untrusted local users.

Deadlock in the Linux kernel's drm/msm (Qualcomm Snapdragon GPU) shrinker causes full kernel hang under memory reclaim pressure. The circular lock dependency arises when the kswapd0 thread holds fs_reclaim and the MSM gem shrinker calls dma_resv_lock(), which internally attempts to re-acquire fs_reclaim - producing a ABBA deadlock that renders the system unresponsive. Kernels in the affected range on Snapdragon-based hardware (Linux 6.17 through pre-patch 7.0.x and 6.18.x) are vulnerable; no public exploit code exists and no active exploitation has been confirmed.

Availability degradation in the Linux kernel's batman-adv throughput meter (tp_meter) subsystem arises from a reference counting race in the receiver shutdown path, where both `batadv_tp_receiver_shutdown()` and `batadv_tp_stop_all()` can simultaneously skip the `tp_vars` reference release when the shutdown timer expires before `timer_shutdown_sync()` is evaluated. The leaked reference accumulates with repeated triggering, progressively exhausting kernel memory resources and resulting in a local denial-of-service condition on systems running the batman-adv mesh networking module. With no public exploit identified at time of analysis and an EPSS score of 0.18% (8th percentile), this is a correctness-class fix with real impact only on systems explicitly running batman-adv.

Denial-of-service via the batman-adv Translation Table (TT) subsystem in the Linux kernel allows a local low-privileged attacker to trigger empty VLAN responses through the global TT state path, causing availability loss in the mesh networking stack. The flaw traces to an incomplete prior fix: commit 16116dac2339 patched the direct TT response path against inconsistent TT TLVLs, but left the indirect global TT response path unguarded, enabling the same class of inconsistency state. No public exploit has been identified and EPSS stands at 0.18% (8th percentile), reflecting low real-world exploitation probability.

Kernel stack memory leaks to userspace through the adm1266 PMBus GPIO driver in the Linux kernel when the ADM1266 hardware returns a shorter-than-expected I2C block-read response. Both adm1266_gpio_get() and adm1266_gpio_get_multiple() assemble a 16-bit status word from two buffer bytes without first verifying that at least two bytes were returned; uninitialized stack data then propagates through the gpiolib subsystem into sysfs and char-device ioctls accessible to local users. No public exploit exists and EPSS probability is 0.18% (8th percentile), consistent with the hardware-specific, locally-exploitable nature of this flaw; patches have been released across all active stable kernel branches.

In the Linux kernel, the following vulnerability has been resolved: ovpn: fix race between deleting interface and adding new peer While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration. It may happen during ovpn_dellink(), when all existing peers are freed and the device is queued for deregistration, but a CMD_PEER_NEW message comes in adding a new peer that takes again a reference to the netdev. At this point there is no way to release the device because we are under the assumption that all peers were already released. Fix the race condition by releasing all peers in ndo_uninit(), when the netdevice has already been removed from the netdev list. Also ovpn_peer_add() has now an extra check that forces the function to bail out if the device reg_state is not REGISTERED. This way any incoming CMD_PEER_NEW racing with the interface deletion routine will simply stop before adding the peer. Note that the above check happens while holding the netdev_lock to prevent racing netdev state changes. ovpn_dellink() is now empty and can be removed.

In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix error return when vfs_mkdir() fails When vfs_mkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdir_error to be reached with ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a proper error pointer. Fix this by extracting the error code from the error pointer when vfs_mkdir() fails.

In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Stop work before releasing hwmon device Sashiko reports: In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called. Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first. If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here. Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed.

In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: remove the software node when deactivating the aggregator The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.

In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix exec_queue leak on width check in stream open In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix dma mapping leak on data setup error We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided. The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too.

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked When sfb has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (sfb in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(sfb) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (sfb). And herein lies the problem. - sfb will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full) [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216 [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0 [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3 [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000 [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000 [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000 [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0 [ 127.598390][ T453] PKRU: 55555554 [ 127.598509][ T453] Call Trace: [ 127.598629][ T453] <TASK> [ 127.598718][ T453] ? mark_held_locks+0x40/0x70 [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0 [ 127.599174][ T453] ? ktime_get+0x137/0x230 [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix setup list UAF on proc write error snd_pcm_oss_proc_write() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setup_list pointing at freed memory. A later OSS device open can then walk the stale list entry in snd_pcm_oss_look_for_setup() and dereference freed memory. Allocate the task name and initialize the setup entry before publishing the entry on setup_list. Also fetch the initial proc read iterator only after taking setup_mutex, so all setup_list traversal follows the same list lifetime rules.

In the Linux kernel, the following vulnerability has been resolved: ethtool: rss: fix indir_table and hkey leak on get_rxfh failure rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation.

In the Linux kernel, the following vulnerability has been resolved: ethtool: module: call ethnl_ops_complete() on module flash errors When validate() fails we are skipping over ethnl_ops_complete() even tho we already called ethnl_ops_begin().

In the Linux kernel, the following vulnerability has been resolved: ethtool: module: avoid leaking a netdev ref on module flash errors module_flash_fw_schedule() is missing undo for setting the "in_progress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock.

In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in sysfs path Since the start of the git history, brport_store() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority). Nowadays, brport_store() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port: Only requires RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the two STP related attributes that require it. Remove the now stale comment from br_switchdev_set_port_flag(). The SWITCHDEV_F_DEFER flag can be removed in net-next. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 372, name: bash preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235) brport_store (net/bridge/br_sysfs_if.c:346) kernfs_fop_write_iter (fs/kernfs/file.c:352) new_sync_write (fs/read_write.c:595) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

In the Linux kernel, the following vulnerability has been resolved: net/sched: fix packet loop on netem when duplicate is on When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency.

In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10

In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer The tagged FIFO path declares iio_buff on the stack with __aligned(8) but no initializer, but there is a hole in the structure, which will then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be copied, but the space between that and the timestamp are not initialized. Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") moved the untagged FIFO path to a kzalloc'd buffer in hw->scan, but for the tagged path it only added the alignment qualifier and not the initializer :( Fix this by just zero-initializing the structure on the stack.

In the Linux kernel, the following vulnerability has been resolved: iio: imu: adis16550: fix stack leak in trigger handler adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigger. Fix this all by just zero-initializing the structure on the stack.

In the Linux kernel, the following vulnerability has been resolved: iio: pressure: bmp280: fix stack leak in bmp580 trigger handler bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer lived in the private data, the move to a stack-local struct dropped the implicit zeroing. bme280_trigger_handler() was fixed up to handle this bug, but this driver was not fixed because there was no padding hole, but rather a short-fill issue. Fix this all by just zero-initializing the structure on the stack.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: validate count before reading Status Update VDO A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer() wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++) regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i); which has two problems: USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed). The byte count latched in RXINFO is the number of bytes the port partner put on the wire, so a malicious partner that transmits a 31-byte frame can drive the loop one byte past the destination if the WCOVE BMC receiver does not enforce the PD object-count limit in hardware. The existing FIXME flagged this as unverified. Independently, regmap_read() takes an unsigned int * and stores a full unsigned int at the destination. Passing the byte pointer msg + i means each iteration writes four bytes; the high three are zero (val_bits is 8) and are normally overwritten by the next iteration, but the final iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration already writes three zero bytes past msg, which sits on the IRQ thread's stack in wcove_typec_irq(). Clamp the loop to sizeof(struct pd_message) and read each register into a local before storing only its low byte, so the copy can never exceed the destination regardless of what RXINFO reports.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_connector_change() The connector number in a UCSI CCI notification is a 7-bit field supplied by the PPM. ucsi_connector_change() uses it to index the ucsi->connector[] array without checking it against the number of connectors the PPM reported at init time, so a buggy or malicious PPM (EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 / glink transports) can drive schedule_work() on memory past the end of the array. Reject connector numbers that are zero or exceed cap.num_connectors before dereferencing the array.

In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due to a PMD check failure, the pgtable allocated earlier via pte_alloc_one() is never freed, causing a memory leak. Added free_abort label to release the pgtable in error path.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn __set_chan_timer() takes a l2cap_chan reference via l2cap_chan_hold() before scheduling the delayed work. The normal path in l2cap_chan_timeout() drops this reference with l2cap_chan_put() at the end, but the early return when chan->conn is NULL skips the put, leaking the reference. Add the missing l2cap_chan_put() before the early return.

In the Linux kernel, the following vulnerability has been resolved: iio: adc: mt6359: fix unchecked return value in mt6358_read_imp In mt6358_read_imp(), the variable val_v is passed to regmap_read() but the return value is not checked. If the read fails, val_v remains uninitialized and its random stack content is subsequently reported as a measurement result. Initialize val_v to zero to ensure a predictable value is reported in case of bus failure and to prevent potential stack data leakage. This also satisfies static analyzers that might otherwise flag the variable as used uninitialized.

In the Linux kernel, the following vulnerability has been resolved: iio: adc: nxp-sar-adc: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero or a negative value to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Also prevent unsigned integer underflow when the computed cycle count is smaller than NXP_SAR_ADC_CONV_TIME, which would wrap the u32 inpsamp to a huge value.

In the Linux kernel, the following vulnerability has been resolved: iio: gyro: itg3200: fix i2c read into the wrong stack location itg3200_read_all_channels() takes `__be16 *buf' as a parameter and fills the i2c_msg destination as `(char *)&buf'. Since `buf' is the parameter (a pointer), `&buf' is the address of the local pointer slot on the stack of itg3200_read_all_channels(), not the address of the caller's scan buffer. The (char *) cast hides the type mismatch. i2c_transfer() therefore writes ITG3200_SCAN_ELEMENTS * sizeof(s16) = 8 bytes into the parameter's stack slot, which is discarded when the function returns. The caller's scan buffer in itg3200_trigger_handler() is never written to, so iio_push_to_buffers_with_timestamp() pushes uninitialised stack contents to userspace via /dev/iio:deviceX every scan -- both a functional bug (no actual gyroscope or temperature data is delivered through the triggered buffer) and an information leak. The non-buffered read_raw() path is unaffected: it goes through itg3200_read_reg_s16() which uses `&out' on a local s16 value, where that is correct. Drop the spurious `&' so the i2c read writes into the caller's buffer.

In the Linux kernel, the following vulnerability has been resolved: iio: gyro: adis16260: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero to the sampling_frequency sysfs attribute triggers a division by zero in the kernel.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: fix division by zero in write_raw Add a zero check for val2 before using it as a divisor when setting the sampling frequency. A user writing a zero fractional part to the sampling_frequency sysfs attribute triggers a division by zero in the kernel.

In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done(); the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled.

In the Linux kernel, the following vulnerability has been resolved: Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem When a configuration file provides an object size that is larger than the driver's known mxt_obj_size(object), the driver intends to discard the extra bytes. The loop iterates using for (i = 0; i < size; i++). Inside the loop, the condition to skip processing extra bytes is: if (i > mxt_obj_size(object)) continue; Since i is a 0-based index, the valid indices for the object are 0 through mxt_obj_size(object) - 1. When i == mxt_obj_size(object), the condition evaluates to false, and the code processes the byte instead of discarding it. This causes the code to calculate byte_offset = reg + i - cfg->start_ofs and writes the byte there, overwriting exactly one byte of the adjacent instance or object. Update the boundary check to skip extra bytes correctly by using >=.

In the Linux kernel, the following vulnerability has been resolved: uio: uio_pci_generic_sva: fix double free of devm_kzalloc() memory uio_pci_sva allocates struct uio_pci_sva_dev with devm_kzalloc() in probe(), but then calls kfree(udev) both on the probe() error path (label out_free) and again in remove(). Because devm_kzalloc() allocations are devres-managed and are freed automatically when the device is detached (including after a failing probe() and during driver unbind), the explicit kfree() can lead to a double free. If probe() fails after devm_kzalloc(), the error path frees udev and devres cleanup will free it again when the core unwinds the partially bound device. On normal driver removal, remove() frees udev and devres will free it again when the device is detached. This issue was identified by a static analysis tool I developed and confirmed by manual review. Fix by removing the manual kfree() calls and dropping the now-unused label.

In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan: fix missing indat transfer sanity check Add the missing sanity check on the size of usa49wg indat transfers to avoid parsing stale or uninitialised slab data.

In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix missing interrupt-in transfer sanity check Add the missing sanity check on the size of interrupt-in transfers to avoid parsing stale or uninitialised slab data (and leaking it to user space).

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow On the non-root path, __tb_property_parse_dir() takes dir_len from entry->length (u16 widened to size_t). Two distinct OOB conditions follow when entry->length < 4: 1. The non-root path begins with kmemdup(&block[dir_offset], sizeof(*dir->uuid), ...) which always reads 4 dwords from dir_offset. tb_property_entry_valid() only enforces dir_offset + entry->length <= block_len, so a crafted entry with dir_offset close to the end of the property block and entry->length in 0..3 passes that gate but lets the UUID copy run off the block (e.g. dir_offset = 497, dir_len = 3 in a 500-dword block reads block[497..501]). 2. After the kmemdup, content_len = dir_len - 4 underflows size_t to ~SIZE_MAX, nentries becomes SIZE_MAX / 4, and the entry walk runs OOB on each iteration until an entry fails validation or the kernel oopses on an unmapped page. Reject dir_len < 4 on the non-root path *before* the UUID kmemdup, which closes both holes. Also move INIT_LIST_HEAD(&dir->properties) up to immediately after the dir allocation so the new error-return path (and the existing uuid-alloc failure path) calling tb_property_free_dir() sees a walkable list rather than the zero-initialized NULL next/prev that list_for_each_entry_safe() would oops on.

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: property: Cap recursion depth in __tb_property_parse_dir() A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tb_property_parse_dir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIES_REQUEST control-plane exchange can trigger this without authentication. Thread a depth counter through tb_property_parse() and __tb_property_parse_dir(), and reject blocks that exceed TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any observed legitimate XDomain layout. Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line.

In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker drivers/scsi/fcoe/fcoe_ctlr.c::fcoe_ctlr_recv_clr_vlink() advanced the descriptor cursor by an attacker-supplied fip_dlen without ever requiring dlen >= sizeof(struct fip_desc) in the default branch. The named descriptor cases (FIP_DT_MAC, FIP_DT_NAME, FIP_DT_VN_ID) checked their per-type minimum lengths, but a FIP_DT_NON_CRITICAL descriptor (fip_dtype >= 128, which the standard requires receivers to silently ignore) skipped that check entirely. An unauthenticated L2 peer on the FCoE control VLAN could hang fcoe_ctlr_recv_work on an fcoe, qedf, or bnx2fc initiator indefinitely by emitting one FIP CVL frame whose single descriptor had fip_dtype == FIP_DT_NON_CRITICAL and fip_dlen == 0: the cursor advanced zero bytes per iteration and the loop condition rlen >= sizeof(*desc) stayed true forever, blocking every subsequent FIP frame on that controller. Tighten the outer dlen guard to also reject dlen < sizeof(struct fip_desc), so a malformed descriptor whose length cannot even cover the descriptor header is rejected before the switch. This is the same lower-bound the named cases already apply and is the minimum scope that closes the loop.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check num_entries in GEM_OP GET_MAPPING_INFO kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL) at amdgpu_gem.c:1050 uses the user-supplied num_entries directly without any upper bounds check. Since num_entries is a __u32 and sizeof(drm_amdgpu_gem_vm_entry) is 32 bytes, a large num_entries produces an allocation exceeding INT_MAX, triggering WARNING in __kvmalloc_node_noprof(), causing a kernel WARNING, TAINT_WARN, and panic on CONFIG_PANIC_ON_WARN=y systems. Add a size bounds check before we invoke the kvzalloc() to reject oversized num_entries early with -EINVAL. (cherry picked from commit 1fe7bf5457f6efd7be60b17e23163ba54341d73d)

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() aie2_populate_range() jumps back to the again label without calling mmput(mm), leaking a reference to the mm_struct. Add the missing mmput() before jumping to again.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.

In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek-gen3: Prevent leaking IRQ domains when IRQ not found In mtk_pcie_setup_irq(), the IRQ domains are allocated before the controller's IRQ is fetched. If the latter fails, the function directly returns an error, without cleaning up the allocated domains. Hence, reverse the order so that the IRQ domains are allocated after the controller's IRQ is found. This was flagged by Sashiko during a review of "[PATCH v6 0/7] PCI: mediatek-gen3: add power control support".

In the Linux kernel, the following vulnerability has been resolved: spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was missing from both probe unwind and remove-time cleanup. Add a devm cleanup action after successful registration so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failures and during device removal.

In the Linux kernel, the following vulnerability has been resolved: net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue() Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: lenovo-wmi-helpers: Fix memory leak in lwmi_dev_evaluate_int() lwmi_dev_evaluate_int() leaks output.pointer when retval == NULL (found by sashiko.dev [1]). Fix it by moving `ret_obj = output.pointer' outside of the `if (retval)' block so that it is always freed by the __free cleanup callback. No functional change intended.

In the Linux kernel, the following vulnerability has been resolved: net: ena: PHC: Check return code before setting timestamp output ena_phc_gettimex64() is setting the output parameter regardless of whether ena_com_phc_get_timestamp() succeeded or failed. When ena_com_phc_get_timestamp() returns an error, the timestamp parameter may contain uninitialized stack memory (e.g., when PHC is disabled or in blocked state) or invalid hardware values. Passing these to userspace via the PTP ioctl is both a security issue (information leak) and a correctness bug. Fix by checking the return code after releasing the lock and only setting the output timestamp on success.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().

In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon: Set fb_display[i]->mode to NULL when the mode is released") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix missing read bio submission on large folio error f2fs_read_data_large_folio() can keep a read bio across multiple readahead folios. If a later folio hits an error before any of its blocks are added to the bio, folio_in_bio is false and the current error path returns immediately after ending that folio. This can leave the bio accumulated for earlier folios unsubmitted. Those folios then never receive read completion, and readers can wait indefinitely on the locked folios. Route errors through the common out path so any pending bio is submitted before returning. Stop consuming more readahead folios once an error is seen, and only wait on and clear the current folio when it was actually added to the bio.

In the Linux kernel, the following vulnerability has been resolved: f2fs: read COW data with the original inode during atomic write When updating an atomic-write file, f2fs_write_begin() may read the previously written data back from the COW inode: prepare_atomic_write_begin() locates the block in the COW inode and sets use_cow, and the read bio is then built with the COW inode: f2fs_submit_page_read(use_cow ? F2FS_I(inode)->cow_inode : inode, ...); and f2fs_grab_read_bio() decides whether to schedule fs-layer decryption (STEP_DECRYPT) for the bio based on that inode via fscrypt_inode_uses_fs_layer_crypto(). However, the folio being filled belongs to the original inode (folio->mapping->host == inode), and the data stored in the COW block was encrypted (or left as plaintext) using the original inode's context, not the COW inode's -- see f2fs_encrypt_one_page(), which keys off fio->page->mapping->host. fscrypt_decrypt_pagecache_blocks() likewise operates on folio->mapping->host. The COW inode is created as a tmpfile in the parent directory and inherits its encryption policy from there. With test_dummy_encryption the newly created COW inode gets the dummy policy and becomes encrypted, while a pre-existing regular file -- created before the policy applied, e.g. already present in the on-disk image -- stays unencrypted. The read path then sets STEP_DECRYPT based on the encrypted COW inode and calls fscrypt_decrypt_pagecache_blocks() on a folio whose host (the unencrypted original inode) has a NULL ->i_crypt_info, dereferencing it: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:fscrypt_decrypt_pagecache_blocks+0xa0/0x310 Workqueue: f2fs_post_read_wq f2fs_post_read_work Call Trace: fscrypt_decrypt_bio+0x1eb/0x340 f2fs_post_read_work+0xba/0x140 process_one_work+0x91c/0x1a40 worker_thread+0x677/0xe90 kthread+0x2bc/0x3a0 The COW inode is only needed to locate the on-disk block, and that block address is already resolved into @blkaddr by prepare_atomic_write_begin() via __find_data_block(cow_inode, ...); f2fs_submit_page_read() then reads from that physical @blkaddr directly, so the inode argument only selects the post-read crypto context, not which block is fetched. Reading with @inode therefore returns the same (latest, not-yet-committed) COW data, while making both the fs-layer decryption decision and the inline crypto path use the correct (original inode's) key. With the COW inode no longer used at the read site, the use_cow flag has no remaining consumer; drop it from f2fs_write_begin() and prepare_atomic_write_begin().

Silent NFS data loss in the Linux kernel's nfsd subsystem allows UNSTABLE write data to be discarded without client notification when deferred writeback errors occur. Affected kernels prior to 6.12.95, 6.18.38, and 7.1.3 fail to rotate the server write verifier (nn->writeverf) in nfsd_vfs_write() and nfsd_commit() after filemap_check_wb_err() detects an error, so NFS clients receive an unchanged verifier on COMMIT and incorrectly conclude their data is durable - violating the UNSTABLE+COMMIT contract in RFC 1813 §3.3.7 and RFC 8881 §18.32. No public exploit exists and EPSS sits at 0.17% (6th percentile), placing this firmly in the operational-reliability rather than active-threat category.

Resource leak in the Linux kernel's ov8856 OmniVision I2C camera driver exposes systems with that hardware to local denial-of-service via kernel memory exhaustion. The driver's ov8856_init_controls() function fails to call v4l2_ctrl_handler_free() on error exit paths, leaving the control handler's allocated memory unreleased each time control registration fails. No public exploit exists and EPSS probability sits at 0.16% (6th percentile), reflecting that this hardware-specific driver code is rarely reachable in practice.

Memory leaks in the Linux kernel's DRM colorop subsystem allow a local low-privileged attacker to gradually exhaust kernel memory by triggering repeated DRM atomic state lifecycle operations, ultimately causing denial of service via out-of-memory conditions. Affected systems are those running Linux kernel versions between the introduction of the colorop subsystem (commit cfc27680ee208cdf7a61cda817b4158c4142595f) and the upstream fix commits, with patched versions available at 7.0.9 and 7.1. No active exploitation is confirmed (not in CISA KEV) and EPSS is extremely low at 0.14% (4th percentile), making this a low-urgency but legitimate kernel hygiene issue requiring patching during normal maintenance cycles.

Persistent GPU denial-of-service in the Linux kernel's drm/msm Qualcomm GPU driver allows a local low-privileged user to render the GPU permanently hung by submitting a single ring workload that triggers an unrecovered fault. The recover_worker function advances the hung ring's fence and early-exits when it detects no further queued work, bypassing the actual GPU reset sequence - leaving the hardware stuck until a reboot. No public exploit has been identified and EPSS is 0.15% (5th percentile), consistent with the narrow hardware and local-access prerequisites.

Missing upper bound validation on `num_of_nodes` in the AMD KFD ioctl handler `kfd_ioctl_get_process_apertures_new` allows a local low-privileged user with access to AMD GPU compute devices to crash the kernel, causing a denial of service. Affected are Linux kernel branches prior to 6.6.140, 6.12.90, 6.18.32, 7.0.9, and 7.1, restricted to systems with AMD GPU hardware and the amdkfd module loaded. EPSS is 0.16% (5th percentile), no public exploit or CISA KEV listing exists, and patched stable releases are available across all active stable branches.

Silent dirty page loss in the Linux kernel's Intel VT-d IOMMU subsystem (iommu/vt-d) allows a low-privileged local actor to trigger an availability impact by attaching a PASID to a nested IOMMU domain whose nesting parent domain already has dirty tracking configured. The kernel fails to block this invalid combination, causing dirty page tracking to silently fail - a condition critical to live VM migration correctness in virtualization environments. No public exploit has been identified; EPSS at 0.17% (6th percentile) reflects extremely low exploitation interest, and the vulnerability is absent from CISA KEV.

Out-of-bounds read in the Linux kernel RDMA/ionic driver's hca_type_show() sysfs handler allows a local user to trigger a kernel crash or leak adjacent kernel memory. The ionic driver's use of an unbounded "%s" format specifier on the 64-byte node_desc field - which is not guaranteed to be NUL-terminated - causes the kernel to read past the end of that field into adjacent members of struct ib_device when exactly 64 bytes have been written. Since ionic supports IB_DEVICE_MODIFY_NODE_DESC, this condition is reachable from unprivileged userspace. No public exploit or CISA KEV listing exists; EPSS is 0.17% (6th percentile), indicating low exploitation probability in the wild.

Multiple ACR mask validation and configuration flaws in the Linux kernel's perf/x86/intel subsystem allow a local low-privileged user to trigger incorrect Intel PMU hardware counter configuration, resulting in high availability impact. Three distinct weaknesses exist: incomplete user-space ACR mask validation permitting cross-group index bits, an early-return logic error that silently skips all subsequent ACR group configuration, and failure to clear stale hardware ACR masks (hw.config1) before writing new values. No public exploit code is identified and EPSS sits at 0.17% (6th percentile), indicating negligible active exploitation probability; this is a maintenance-patch priority rather than an emergency.

SELinux avdcache auditing in the Linux kernel incorrectly reuses a previously computed audited vector from avc_audit_required() rather than recomputing it against the current access request and its allow/deny outcome, causing certain permission checks to go silently unlogged. Affected are local, low-privileged users on kernels containing the per-task avdcache introduced at commit dde3a5d0f4dce1d1a6095e6b8eeb59b75d28fb3b, through versions prior to 6.18.30, 7.0.7, and 7.1. An attacker exploiting this gap can perform SELinux-policy-violating operations - such as directory writes following a cached directory search - that generate no audit record, directly undermining intrusion detection and compliance monitoring that depends on SELinux audit logs. No public exploit exists and EPSS is at the 6th percentile; however, organizations with strict SELinux audit compliance requirements face elevated effective risk.

Improper exception handling in devpush's storage reset worker exposes a limited integrity-impact flaw for adjacent network attackers with low-privilege access. The `reset_storage` function in `app/workers/tasks/storage.py` fails to correctly check or handle exceptional conditions (CWE-703), meaning that under specific error scenarios, the storage reset process may enter an inconsistent or exploitable state. With a CVSS 4.0 score of 2.1, no public exploit code identified, and no active exploitation confirmed, this represents a low-priority finding that nonetheless warrants a vendor patch given the unresponsive upstream maintainer.

Cleartext storage of blog entry protection passwords in django-blog-zinnia (all versions through 0.20) exposes those passwords to any local actor with read access to the application's storage layer. The flaw resides in the Protected Entry Password Handler at `zinnia/views/mixins/entry_protection.py`, where passwords used to gate access to individual blog entries are persisted without hashing or encryption. No public exploit code exists and no actively exploited status has been confirmed; the project maintainer has not responded to the coordinated disclosure, making a vendor-issued patch unlikely.

Race condition in awesto django-shop's Purchase Stock Handler allows a remotely authenticated attacker with low privileges to manipulate inventory data by triggering concurrent purchase requests. Affected versions span all releases up to and including 1.2.4. A publicly available proof-of-concept exists in the project's GitHub issue tracker, and the vendor has not responded to responsible disclosure - no patch has been released. EPSS data is absent, but the CVSS 4.0 score of 2.3 reflects the high attack complexity and limited impact scope.

Race condition in Allegro Ralph's hostname allocation handler allows adjacent, low-privileged attackers to corrupt hostname assignment logic, producing duplicate or incorrect hostname entries. The flaw resides in the AssetLastHostname.increment_hostname function within src/ralph/assets/models/assets.py, where concurrent manipulation of the counter argument creates a time-of-check/time-of-use window. The project maintainers were notified via an issue report but have not yet responded, leaving no available patch; a proof-of-concept exploit has been publicly disclosed on GitHub. No public exploit identified at time of analysis beyond the PoC, and KEV status is not confirmed.

Race condition in django-tastypie's throttle module (versions up to 0.15.1) allows authenticated remote users to bypass API rate limiting controls by exploiting a time-of-check to time-of-use (TOCTOU) window in the CacheThrottle and CacheDBThrottle classes. The CVSS 4.0 score of 2.3 with high attack complexity (AC:H) and low-privilege requirement (PR:L) reflects the limited real-world risk; impacts are constrained to minor information disclosure and throttle bypass without subsequent-system effects. No public exploit has been identified and the project maintainers have not yet responded to the disclosure.