Information Disclosure

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely".

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU: lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ... Add a default switch case to fix the panic as below: Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4

{weight,idle,bandwidth}() cache scx_root before acquiring scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs. If the loaded scheduler is disabled and freed (via RCU work) and another is enabled between the naked load and the rwsem acquire, the reader sees scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...). scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section correlates @sch with the enabled snapshot.

In the Linux kernel, the following vulnerability has been resolved: 8021q: delete cleared egress QoS mappings vlan_dev_set_egress_priority() currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities therefore accumulate mapping nodes until device teardown and leak memory. Delete mappings when vlan_prio is cleared instead of keeping tombstones. Now that the egress mapping lists are RCU protected, the node can be unlinked safely and freed after a grace period.

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.

In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.

In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: control built-in cs manually The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu() Two bugs exist in the vCPU initialisation path: 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup path jumps to 'unlock' without calling unpin_host_vcpu() or unpin_host_sve_state(), permanently leaking pin references on the host vCPU and SVE state pages. Extract a register_hyp_vcpu() helper that performs the checks and the store. When register_hyp_vcpu() returns an error, call unpin_host_vcpu() and unpin_host_sve_state() inline before falling through to the existing 'unlock' label. 2. register_hyp_vcpu() publishes the new vCPU pointer into 'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU object. Ensure the store uses smp_store_release() and the load uses smp_load_acquire(). While 'vm_table_lock' currently serialises the store and the load, these barriers ensure the reader sees the fully initialised 'hyp_vcpu' object even if there were a lockless path or if the lock's own ordering guarantees were insufficient for nested object initialization.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up.

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening.

In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix VF illegal register access Register WX_CFG_PORT_ST is a PF restricted register. When a VF is initialized, attempting to read this register triggers an illegal register access, which lead to a system hang. When the device is VF, the bus function ID can be obtained directly from the PCI_FUNC(pdev->devfn).

In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: fix kmemleak caused by incorrect chip_data lookup The kmemleak reports the following memory leak: Unreferenced object 0xc0000002a7fbc640 (size 64): comm "kworker/8:1", pid 540, jiffies 4294937872 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................ 00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................ backtrace (crc 177d48f6): __kmalloc_cache_noprof+0x520/0x730 xive_irq_alloc_data.constprop.0+0x40/0xe0 xive_irq_domain_alloc+0xd0/0x1b0 irq_domain_alloc_irqs_parent+0x44/0x6c pseries_irq_domain_alloc+0x1cc/0x354 irq_domain_alloc_irqs_parent+0x44/0x6c msi_domain_alloc+0xb0/0x220 irq_domain_alloc_irqs_locked+0x138/0x4d0 __irq_domain_alloc_irqs+0x8c/0xfc __msi_domain_alloc_irqs+0x214/0x4d8 msi_domain_alloc_irqs_all_locked+0x70/0xf8 pci_msi_setup_msi_irqs+0x60/0x78 __pci_enable_msix_range+0x54c/0x98c pci_alloc_irq_vectors_affinity+0x16c/0x1d4 nvme_pci_enable+0xac/0x9c0 [nvme] nvme_probe+0x340/0x764 [nvme] This occurs when allocating MSI-X vectors for an NVMe device. During allocation the XIVE code creates a struct xive_irq_data and stores it in irq_data->chip_data. When the MSI-X irqdomain is later freed, xive_irq_free_data() is responsible for retrieving this structure and freeing it. However, after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers"), xive_irq_free_data() retrieves the chip_data using irq_get_chip_data(), which looks up the data through the child domain. This is incorrect because the XIVE-specific irq data is associated with the XIVE (parent) domain. As a result the lookup fails and the allocated struct xive_irq_data is never freed, leading to the kmemleak report shown above. Fix this by retrieving the irq_data from the correct domain using irq_domain_get_irq_data() and then accessing the chip_data via irq_data_get_irq_chip_data().

In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndr_pull_security_descriptor failed: Range Error", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration cros_typec_register_thunderbolt() missed initializing the `adata->lock` mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in cros_typec_altmode_work()). Initialize the mutex in cros_typec_register_thunderbolt() to fix the issue.

{ __u8 broadcast[32]; }; The function then copies dev->broadcast into it using dev->addr_len as the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: check for nEPT/nNPT in slow flush hypercalls Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself.

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info() error path When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.

In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound. First there is a double i-- on the first failure path due to the while loop having a i--, remove it. Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not undone due to the above i--.

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.

In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 ("isofs: Prevent the use of too small fid") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.

{on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcg_path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock.

In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.

In the Linux kernel, the following vulnerability has been resolved: block: add pgmap check to biovec_phys_mergeable biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps.

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt); check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path. Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in create_big_sync Add hci_conn_valid() check in create_big_sync() to detect stale connections before proceeding with BIG creation. Handle the resulting -ECANCELED in create_big_complete() and re-validate the connection under hci_dev_lock() before dereferencing, matching the pattern used by create_le_conn_complete() and create_pa_complete(). Keep the hci_conn object alive across the async boundary by taking a reference via hci_conn_get() when queueing create_big_sync(), and dropping it in the completion callback. The refcount and the lock are complementary: the refcount keeps the object allocated, while hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on hdev->conn_hash, as required by hci_conn_del(). hci_conn_put() is called outside hci_dev_unlock() so the final put (which resolves to kfree() via bt_link_release) does not run under hdev->lock, though the release path would be safe either way. Without this, create_big_complete() would unconditionally dereference the conn pointer on error, causing a use-after-free via hci_connect_cfm() and hci_conn_del().

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change.

In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix memory leak on ulpi_register() error paths Commit 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") removed kfree(ulpi) from ulpi_register_interface() to fix a double-free when device_register() fails. But when ulpi_of_register() or ulpi_read_id() fail before device_register() is called, the ulpi allocation is leaked. Add kfree(ulpi) on both error paths to properly clean up the allocation.

In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.

In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.

In the Linux kernel, the following vulnerability has been resolved: eventfs: Hold eventfs_mutex and SRCU when remount walks events Commit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the events descriptor") had eventfs_set_attrs() recurse through ei->children on remount. The walk only holds the rcu_read_lock() taken by tracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex. Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo "p:kp submit_bio" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done Wrap the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() that take eventfs_mutex and srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract. Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU.

In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Limit NVMe request size to 2 MiB The HBA firmware reports NVMe MDTS values based on the underlying drive capability. However, because the driver allocates a fixed 4K buffer for the PRP list, accommodating at most 512 entries, the driver supports a maximum I/O transfer size of 2 MiB. Limit max_hw_sectors to the smaller of the reported MDTS and the 2 MiB driver limit to prevent issuing oversized I/O that may lead to a kernel oops.

In the Linux kernel, the following vulnerability has been resolved: selinux: use sk blob accessor in socket permission helpers SELinux socket state lives in the composite LSM socket blob. sock_has_perm() and nlmsg_sock_has_extended_perms() currently dereference sk->sk_security directly, which assumes the SELinux socket blob is at offset zero. In stacked configurations that assumption does not hold. If another LSM allocates socket blob storage before SELinux, these helpers may read the wrong blob and feed invalid SID and class values into AVC checks. Use selinux_sock() instead of accessing sk->sk_security directly.

Arbitrary file read in KubeVirt's virt-exportserver component allows authenticated namespace users to exfiltrate sensitive files from the exporter pod via symlink-based path traversal in the VMExport directory endpoint. The flaw, reported by Red Hat and impacting Red Hat OpenShift Virtualization 4, carries a CVSS 7.7 score driven by scope change and high confidentiality impact, though no public exploit identified at time of analysis.

Sensitive information exposure in the PDF Embedder WordPress plugin (all versions through 4.9.3) allows authenticated attackers with contributor-level access or higher to extract configuration data via the enqueue_block_assets hook. The severity of impact is installation-dependent: on sites running the premium add-on with a saved license key, attackers can exfiltrate that license key; on Lite-only installations, exposed data is limited to non-sensitive viewer settings such as dimensions, toolbar preferences, and usage tracking. No public exploit identified at time of analysis, and this CVE does not appear in the CISA KEV catalog.

Keycloak's ClientRegistrationAuth component can be crashed by a remote unauthenticated attacker through a specially crafted POST request bearing a malformed 'Authorization: Bearer' header, triggering an unhandled ArrayIndexOutOfBoundsException and returning HTTP 500 to all subsequent callers of the affected endpoint. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms zero prerequisites for exploitation beyond network reachability, making any publicly exposed Keycloak client registration endpoint a viable target. No public exploit has been identified at time of analysis and no EPSS data was supplied, but the trivial attack mechanics mean no specialized tooling is required to reproduce the denial of service.

Refresh token replay in Keycloak allows a remote attacker who has previously captured a user's refresh token to reuse that token after it has been revoked, bypassing session expiration controls. The vulnerability surfaces specifically when revokeRefreshToken=true is configured alongside persistent session storage, and is triggered by a server restart that resets the internal timing mechanisms responsible for enforcing token revocation. Successful exploitation can yield full account takeover, information disclosure, or privilege escalation; no public exploit identified at time of analysis and the CVE does not appear in CISA KEV.

Insecure Direct Object Reference in the Meta Field Block WordPress plugin (all versions through 1.5.1) allows authenticated attackers with Contributor-level access to read arbitrary user meta, post meta, and term meta data from any object in the database by supplying unchecked object IDs and types via block attributes. The CVSS vector (AV:N/AC:L/PR:L/UI:N/C:H) confirms this is remotely exploitable with low privilege and no user interaction, with a full confidentiality impact on metadata. Risk is materially elevated on sites running WooCommerce or similar plugins that persist PII - names, billing addresses, phone numbers, emails - in meta fields. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog at time of analysis.

Arbitrary file write in Veeam Backup & Replication 13 (≤13.0.1) on Linux-based deployments allows an authenticated Backup Administrator to write files anywhere on the server filesystem, enabling code execution and full host compromise. CVSS 4.0 scores this 8.6 (High) due to network-reachable exploitation with high impact across confidentiality, integrity, and availability, though high privileges are required. No public exploit identified at time of analysis.

Information disclosure in Red Hat Build of Keycloak exposes client protocol type to unauthenticated remote attackers via error message enumeration. By submitting specially crafted SOAP requests targeting the SAML ECP (Enhanced Client or Proxy) endpoint with varying client IDs, an attacker can observe distinct faultstring values in server responses and map which clients use which protocol types. No authentication, user interaction, or elevated privileges are required, and the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms exploitation is straightforward against any exposed instance. No public exploit code has been identified and this CVE is not listed in the CISA KEV catalog at time of analysis.

Policy enforcement bypass in Red Hat Build of Keycloak's Client Policies framework allows unauthenticated remote attackers to obtain OAuth2 tokens via the Resource Owner Password Credentials (ROPC) grant even when an explicit `reject-ropc-grant` executor is configured to block it. The bypass is triggered specifically when certain condition providers - client-type, client-roles, client-attributes, or client-scopes - are used within the same policy, causing silent executor skipping rather than a fail-closed enforcement error. Successful exploitation results in unauthorized token issuance and potential information disclosure. No public exploit code and no CISA KEV listing have been identified at time of analysis.

Unauthenticated information disclosure in FUXA 1.3.0 (web-based SCADA/HMI server, npm package fuxa-server) lets remote attackers retrieve full project configuration from the GET /api/project endpoint even when secureEnabled is turned on. The exposed data includes server-side script source code, device connection details, HMI view layouts with tag bindings, and alarm definitions. Publicly available exploit code exists (a single unauthenticated curl request demonstrated in the GitHub advisory), and the CVSS vector confirms unauthenticated network exploitation rated 7.5 (confidentiality-only impact); there is no public exploit identified as actively exploited in CISA KEV.

Cross-origin data exposure in Google's MCP Toolbox for Databases stems from the SSE initialization handler unconditionally emitting an `Access-Control-Allow-Origin: *` header, which overrides the `allowed-origins`/`allowed-hosts` controls added during beta and opens the endpoint to DNS rebinding. Any deployment using the SSE transport under MCP specification v2024-11-05 is affected, letting a remote attacker who lures a victim to a malicious web page read the victim's Toolbox/database tool responses cross-origin. Rated CVSS 4.0 9.4 with an upstream fix merged in PR #3054; no public exploit has been identified and the issue is not on CISA KEV.

Exponential memory exhaustion in Symfony's YAML parser (symfony/yaml) allows denial of service through crafted YAML documents exploiting the classic 'Billion Laughs' pattern. The Symfony\Component\Yaml\Parser resolves collection aliases (*anchor references to arrays, stdClass, or TaggedValue objects) recursively without any expansion limit, enabling a tiny input document to trigger multi-gigabyte in-memory structures at parse time. Any application that parses untrusted YAML using the affected component versions is vulnerable, spanning symfony/yaml and symfony/symfony packages across the 5.4, 6.x, and 7.x release trains. No public exploit is identified at time of analysis, though the advisory and fix commit include working PoC YAML payloads demonstrating the attack.

Unauthenticated information disclosure in Automad CMS (Composer package automad/automad) versions 2.0.0-alpha.1 through 2.0.0-beta.27 lets any remote attacker retrieve the bcrypt password hash of every administrator account through a single POST request to the setup endpoint. The /_api/user-collection/create-first-user endpoint stays publicly reachable after initial configuration and returns fully serialized user records, and in 2.0.0-beta.27 it additionally leaks TOTP two-factor secrets. There is no public exploit identified at time of analysis, but exploitation is trivial (network, no authentication, no user interaction) and the issue was fixed in 2.0.0-beta.28.

Thread-safety flaws in pam_usb's deny_remote feature allow incorrect remote-session authentication decisions in display managers like GDM that run concurrent authentication threads. Three functions use the non-reentrant strtok(), whose single global state pointer can be overwritten mid-parse by a racing thread, corrupting tmux session data or /proc environ analysis used to classify sessions as local or remote. Compounding this, strtok() is called directly on the raw pointer returned by getenv(TMUX), inserting NUL bytes directly into the live process environment block and permanently corrupting the TMUX variable for all subsequent authentications in that long-lived process. An attacker with local low-privileged access on an affected system running GDM could exploit thread interleaving to cause deny_remote=true to pass a remote session as local. No public exploit identified at time of analysis; CVSS 6.3 with local, high-complexity attack vector.

Symfony's OidcTokenHandler accepts bearer JWTs that omit the audience (aud), issuer (iss), and expiry (exp) claims, bypassing critical security constraints enforced by OpenID Connect. Applications using symfony/security-http's OIDC access-token authentication are exposed to authentication bypass: an attacker presenting a validly-signed JWT that simply lacks these claims will be authenticated without audience binding, issuer verification, or expiry enforcement. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the patch is available and upgrade is strongly recommended for any application using Symfony's built-in OIDC handler.

Argument injection in Symfony Mailer's SendmailTransport component allows an attacker who controls recipient email addresses to inject arbitrary sendmail command-line options when the transport operates in -t mode. The flaw affects symfony/mailer and symfony/symfony across the 5.4, 6.x, and 7.x branches, with fixed releases confirmed at 5.4.52, 6.4.40, and 7.4.12. No public exploit code or CISA KEV listing exists at time of analysis, but the vulnerability is exploitable wherever application logic permits user-influenced recipient addresses and -t mode is configured.

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/19. A-ADV-20260126-02] CVE-2026-42329: DFIR-IRIS before 2.4.28 Open Redirect (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260126-03] CVE-2026-42538: DFIR-IRIS before 2.4.28 Insecure File Upload (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260126-04] CVE-2026-42539: DFIR-IRIS before 2.4.28 Excessive Data Exposure (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-01] CVE-2026-42540: DFIR-IRIS before 2.4.28 Mass Assignment (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-03] CVE-2026-42543: DFIR-IRIS be

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/19. 0126-03] CVE-2026-42538: DFIR-IRIS before 2.4.28 Insecure File Upload (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260126-04] CVE-2026-42539: DFIR-IRIS before 2.4.28 Excessive Data Exposure (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-01] CVE-2026-42540: DFIR-IRIS before 2.4.28 Mass Assignment (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-03] CVE-2026-42543: DFIR-IRIS before 2.4.28 Cross-Site Request Forgery (CSRF) (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-05] CVE-2026-42547: DF

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/19. -20260126-04] CVE-2026-42539: DFIR-IRIS before 2.4.28 Excessive Data Exposure (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-01] CVE-2026-42540: DFIR-IRIS before 2.4.28 Mass Assignment (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-03] CVE-2026-42543: DFIR-IRIS before 2.4.28 Cross-Site Request Forgery (CSRF) (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-05] CVE-2026-42547: DFIR-IRIS before 2.4.28 Alerts Can be Falsely Attributed to Customers (SBA Research Security Advisory <advisory@...-resea…) CVE-2026-47323: A

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/19. exploit in haveged, fixed in 1.9.21, CVE-2026-41054 (Steffen Nurpmeso <steffen@...oden.eu>) PinTheft Linux LPE (Sam James <sam@...too.org>) [SBA-ADV-20260126-02] CVE-2026-42329: DFIR-IRIS before 2.4.28 Open Redirect (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260126-03] CVE-2026-42538: DFIR-IRIS before 2.4.28 Insecure File Upload (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260126-04] CVE-2026-42539: DFIR-IRIS before 2.4.28 Excessive Data Exposure (SBA Research Security Advisory <advisory@...-research.org>) [SBA-ADV-20260128-01] CVE-2026-42540: DFIR-IR

Email-header and SMTP command injection (CWE-93) in Symfony's Mime component (symfony/mime, also shipped in the symfony/symfony monolith) lets an attacker who controls any address value smuggle CRLF sequences past a trusted validation boundary. The Address value-object - used for every Mailer to/cc/bcc/from/reply-to address - accepts an RFC-5322 quoted-string local-part containing raw carriage-return/line-feed bytes, which is later emitted verbatim into rendered message headers and into SmtpTransport's MAIL FROM/RCPT TO lines, allowing injection of new headers (e.g. an unauthorized Bcc) or new SMTP commands. It affects symfony/mime before 5.4.52, 6.4.40, and 7.4.12; there is no public exploit identified at time of analysis and the issue is not in CISA KEV.

Symfony HtmlSanitizer's UrlSanitizer::parse() passes Unicode BiDi override characters (U+202A-U+202E, U+2066-U+2069) unchanged into href and src HTML attributes, enabling visual URL spoofing against any application that renders sanitized user-supplied HTML to other users. All HtmlSanitizer configurations that permit links or media elements are affected across symfony/html-sanitizer 6.1.0-6.4.39, 7.0.0-7.4.11, and 8.0.0-8.0.11, as well as the bundled symfony/symfony 6.1.0-6.4.39. No public exploit has been released and this CVE is not listed in CISA KEV, but the BiDi spoofing technique is a well-documented, low-complexity phishing primitive requiring no authentication on the attacker's side.

PATH hijacking in pam_usb helper tools prior to version 0.9.0 allows a local low-privileged attacker who can manipulate the process environment to substitute malicious binaries for those called by pamusb-check, pamusb-conf, and pamusb-keyring-unlock-gnome, resulting in high confidentiality and integrity impact. The root cause is CWE-427 (Uncontrolled Search Path Element): all three tools resolved external binaries - including id, whoami, pidof, gnome-keyring-daemon, and pamusb-check itself - through the attacker-controllable PATH variable rather than hardcoded absolute paths. No public exploit code exists and this vulnerability is not listed in CISA KEV at time of analysis.

Concurrent PAM invocations in pam_usb prior to 0.9.1 expose a process-wide static pointer race condition in src/log.c, where each PAM call overwrites a shared static pointer with the address of a stack-local variable. When multiple threads invoke the PAM stack simultaneously - a normal condition in multi-threaded Linux services such as SSH daemons or display managers - one thread's logging pointer can reference another thread's already-deallocated stack frame, causing availability loss (crash/hang) or limited integrity corruption. No public exploit has been identified at time of analysis, and this is not listed in CISA KEV.

Denial of service in CrowdSec Local API (LAPI) versions 1.7.0 through 1.7.7 allows an attacker to exhaust server heap memory by submitting concurrent gzip-compressed requests to unauthenticated endpoints, causing the OS to forcibly terminate the LAPI process. The root cause is the global use of gin-contrib/gzip's DefaultDecompressHandle middleware in pkg/apiserver/controllers/controller.go without any cap on decompressed body size, enabling classic zip-bomb-style memory exhaustion. This is exploitable only when LAPI is network-exposed (non-default multi-server deployments); default single-server configurations bind LAPI to loopback only. No public exploit or KEV listing exists at time of analysis; patch version 1.7.8 is available.

Authentication bypass in pam_usb prior to 0.9.1 allows a local low-privileged user to circumvent hardware token requirements by exploiting silent EACCES error suppression in the virtual input device scanner. When the PAM module's evdev.c component fails to open /dev/input/event* nodes due to permission errors, it returns a false negative indicating no virtual devices are present, and the caller in local.c proceeds with authentication as if the hardware check passed cleanly. No public exploit has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Remote code execution in Langroid before 0.63.0 arises because its SQLChatAgent executes SQL text generated by an LLM, and that LLM is steerable through prompt injection — including indirect injection via data returned from the database into the model's context. When the agent connects with a database role holding code-execution or filesystem privileges, an attacker who shapes the agent's input can drive emission of dialect-specific primitives like PostgreSQL's COPY ... FROM PROGRAM to run OS commands on the database host. A full working proof-of-concept (Base64-smuggled COPY FROM PROGRAM running 'id') is published in the GitHub advisory; there is no entry in CISA KEV, so this reflects publicly available exploit code rather than confirmed active exploitation.

Unauthorized CI data access in GitLab CE/EE allows an authenticated low-privileged user to read CI pipeline data from a ref type (branch, tag, or merge request ref) other than the one they are authorized to view, under certain unspecified conditions. All GitLab installations - both Community and Enterprise editions - running versions from 12.7 through the unpatched releases are affected. The vulnerability is classified as information disclosure with low confidentiality impact; no public exploit code has been identified at time of analysis and it is not listed in the CISA KEV catalog.

Sandbox escape in OneUptime before 10.0.98 lets an authenticated user break out of the Node.js vm-module isolation that the platform relies on to safely run untrusted logic, gaining code execution in the host context. The vm module was never intended as a security boundary and can be escaped using error objects and infinite recursion, yielding full confidentiality, integrity, and availability impact (CVSS 9.9, scope-changed). No public exploit is identified at time of analysis, but the escape technique is well-documented for the Node.js vm module generally.

Server-side request forgery in Budibase before 3.39.0 lets an authenticated user with the BUILDER role coerce the platform into making attacker-controlled outbound requests by setting a malicious OAuth2 token endpoint URL. Because the token fetch path bypassed the codebase's existing SSRF-blocking HTTP wrapper, responses from internal-only services such as the CouchDB database or cloud instance metadata endpoints can be exfiltrated. No public exploit identified at time of analysis, but the flaw is straightforward to trigger and EPSS/KEV signals were not supplied.

Sensitive credential disclosure in Budibase low-code platform versions prior to 3.38.3 allows any authenticated low-privilege user to retrieve a configured Snowflake datasource's private key in plaintext. The flaw stems from an incomplete secret-masking filter that only redacts fields typed as PASSWORD, leaving the Snowflake privateKey field (typed SENSITIVE_LONGFORM) exposed through the GET /api/datasources/:datasourceId endpoint. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; it is fixed in 3.38.3.

Two-factor authentication bypass via TOTP secret disclosure affects FileRise self-hosted file manager before 3.12.0, where the /api/totp_setup.php endpoint can be reached from the intermediate 'pending_login_user' session state that exists after a correct password but before the TOTP check. For accounts that already have TOTP enabled, the endpoint decrypts and returns the existing TOTP secret inside the enrollment QR PNG rather than refusing, so an attacker who already holds the victim's password can extract the seed, compute a valid one-time code, and complete login without the victim's authenticator. No public exploit has been identified at time of analysis and no EPSS score is provided, but the issue fully defeats the second authentication factor.

Embedded malicious code in Nx Console (the editor extension for Nx and Lerna) version 18.95.0 turned a trusted developer tool into a trojan during a brief publish window on 19 May 2026. The poisoned build was live on the Visual Studio Marketplace for roughly 18 minutes (12:30-12:48 UTC) and on OpenVSX for roughly 36 minutes (12:33-13:09 UTC); any developer who installed or auto-updated during those windows executed attacker-controlled code inside their IDE, tagged here as information disclosure. It is confirmed actively exploited (CISA KEV) and publicly available exploit code exists, with CISA SSVC rating exploitation as active, automatable, and total technical impact; the clean release 18.100.0 is the fix.

Unsalted SHA-256 password hashing in WeGIA exposes all stored credentials to rainbow table attacks in versions prior to 3.7.3. Both the login flow (html/login.php) and the password-change flow (controle/FuncionarioControle.php) use PHP's hash() with SHA-256 and no per-user salt, meaning identical passwords always produce identical digests and a single precomputed table can compromise the entire credential database at once. No public exploit has been identified at time of analysis and no KEV listing exists, but exploitability is high once hash data is obtained - the attack requires only standard rainbow table tooling and no cryptographic skill.

Authentication bypass in SpSoft AppLock 7.9.40 for Android allows a local attacker with physical device access to circumvent fingerprint or PIN protection and access locked applications such as Chrome. The flaw stems from the app's reliance on a custom UI overlay rather than enforcing authentication at a deeper system level - cascading interface navigation triggered via advertisement or browser intents exposes routes that allow the attacker to exit the lock screen without re-authenticating. No public exploitation (CISA KEV) has been confirmed, but a researcher-published proof-of-concept exists on GitHub, and EPSS is low at 0.04% (11th percentile), consistent with the physical-access requirement limiting opportunistic exploitation.

Protocol-relative URL injection in Symfony's UrlGenerator allows open redirect via regex alternation bypass in route parameter validation. When route requirements use alternation patterns (e.g., `_locale: 'en|fr|vi|de'`), the validation regex `#^REQUIREMENT$#` fails to anchor middle alternatives due to regex operator precedence, enabling substring matching against attacker-supplied values. An attacker who can influence route parameters fed into the Twig `path()`/`url()` helpers can inject a value like `/evil.com` - which satisfies the requirement by containing `vi` as a substring - causing UrlGenerator to produce `//evil.com/...`, a protocol-relative URL the browser navigates off-site. No public exploit is identified at time of analysis, and the vulnerability is not listed in CISA KEV; patches are released across all supported Symfony branches.

Path traversal in Webmin's mailboxes component before version 2.640 lets an authenticated user write saved attachment files outside the intended directory by controlling the attachment's filename. The flaw lives in mailboxes/detachall.cgi, which constructs the on-disk filename directly from the email attachment's MIME name without stripping path separators, so a crafted name can redirect the write to an attacker-chosen location. Carrying a CVSS 4.0 base score of 9.4 with total technical impact, the issue is fixed in 2.640; CISA's SSVC framework currently lists exploitation status as none and no public exploit has been identified.

Arbitrary file read on the Jenkins controller is possible in the Jenkins 'Pipeline: Groovy Libraries Plugin' (version 797.v90ea_a_9b_e45a_0 and earlier), where the plugin fails to prohibit symbolic links inside shared libraries. An attacker who can control the contents of a shared library consumed by a Pipeline job can plant symlinks that resolve to sensitive files (credentials, secrets, configuration) on the controller filesystem and exfiltrate them through the build. There is no public exploit identified at time of analysis, and SSVC marks exploitation status as none, so this is a patch-and-move-on issue rather than an active-exploitation emergency.

Arbitrary file disclosure in the Jenkins Email Extension Plugin (email-ext) versions 1933.v45cec755423f and earlier lets users who can control email content abuse the data-inline image attribute to supply file: URLs, causing the Jenkins controller to read local files and embed their contents as base64 inside outgoing emails. An authenticated attacker with rights to edit job email configuration or templates (CVSS PR:L) can exfiltrate controller secrets, credentials, and configuration. There is no public exploit identified at time of analysis and CISA's SSVC rates exploitation as none, but the CVSS 8.8 score and 'total' technical impact make controller secret theft a serious concern in shared Jenkins environments.

Information disclosure in IBM Business Automation Workflow (containers and traditional deployments) exposes internal database schema details through application error messages to authenticated low-privilege users. Affecting versions across the 24.0.0, 24.0.1, 25.0.0, and 25.0.1 release lines, a network-accessible authenticated attacker can deliberately trigger error conditions to harvest database structure information - table names, column names, or schema layout - without needing elevated permissions. No public exploit code exists and no active exploitation is confirmed; SSVC assessment classifies this as non-automatable with partial technical impact, consistent with its limited confidentiality scope.

Credential exposure in IBM Guardium Data Protection's Long Term Retention (LTR) add-on feature allows authenticated network users to obtain sensitive credentials when the system is operating in debug mode. Affected versions are 12.2.1 (up to and including Fix Pack 4.4.7 Fix Pack 1) and 12.2.2. The high confidentiality impact (C:H) reflects that fully valid credentials - not just partial data - may be disclosed, potentially enabling lateral movement or privilege escalation within the data protection infrastructure. No public exploit has been identified at time of analysis, and SSVC assessment confirms no active exploitation.

Denial-of-service via uncontrolled recursion in the IBM i Integrated Language Environment (ILE) compiler affects versions 7.3, 7.4, 7.5 (≤12.1.4), and 7.6 (≤11.5.9). An authenticated network attacker can crash or hang the ILE compiler by submitting specially crafted source code containing a specific combination of statements that triggers infinite or deeply nested recursive processing. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, though the low complexity and authenticated-only barrier makes this plausible for insider threat or compromised credential scenarios.

Sensitive information disclosure in IBM App Connect Enterprise 13.0.1.0 through 13.0.7.0 exposes potentially sensitive data via log files accessible to local users. The CVSS vector (AV:L/PR:L) confirms exploitation requires local, low-privileged authenticated access, limiting the attack surface to users already present on the system. No public exploit has been identified and CISA SSVC rates exploitation as none, but the confidentiality impact is rated High, meaning successful access to log files could yield significant sensitive data.

Local File Inclusion in the SeedProd Pro WordPress plugin (all versions before 6.19.5) lets an authenticated, low-privileged user coerce a PHP include/require statement into loading attacker-influenced local files, leading to disclosure of sensitive server-side files and potential code execution if a controllable file (e.g. an uploaded payload or log) can be included. The flaw, reported by Patchstack and classified CWE-98, carries a CVSS 3.1 base score of 7.5 with high attack complexity. There is no public exploit identified at time of analysis, and CISA SSVC rates exploitation as 'none', indicating this is currently a patch-and-move-on item rather than an emergency.

Out-of-bounds read in libusb's parse_iad_array() function (descriptor.c) affects all releases before 1.0.30, enabling local attackers in virtualized environments with USB passthrough to crash libusb-dependent processes via a crafted USB descriptor. The off-by-one error causes the bounds check to evaluate against the original total buffer size rather than the remaining unparsed size, allowing a one-byte read past the end of the malloc allocation when a descriptor's bLength is set to exactly (total_size - 1). No public exploit code exists and the vulnerability is absent from CISA KEV; a vendor-released patch is confirmed in v1.0.30.

In the Linux kernel, the following vulnerability has been resolved: can: ucan: 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 control message buffer lifetime so that it is released on driver unbind.

In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.

In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.

In the Linux kernel, the following vulnerability has been resolved: fs: afs: revert mmap_prepare() change Partially reverts commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()"). This is because the .mmap invocation establishes a refcount, but .mmap_prepare is called at a point where a merge or an allocation failure might happen after the call, which would leak the refcount increment. Functionality is being added to permit the use of .mmap_prepare in this case, but in the interim, we need to fix this.

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.