OESA-2026-2676

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

parisc: Drop WARNONONCE() from flushcachevmap

I have observed warning to occassionally trigger.(CVE-2025-39781)

In the Linux kernel, the following vulnerability has been resolved:

MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits

Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASMiLAmostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASMiLAmostly (and now UASMiLA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the _readmostly section.

This corruption was observed because the variable _cpuprimarythreadmask was corrupted, causing a hang very early during boot.

This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insnlamcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the no_hw_access flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smp_mb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: reject new transactions if the fs is fully read-only

[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:

BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:findfreeextentupdateloop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:findfreeextent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfsreserveextent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfsalloctreeblock+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfsforcecowblock+0x578/0x2410 fs/btrfs/ctree.c:517 btrfscowblock+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfssearchslot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfstruncateinodeitems+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfsevict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentrykill+0x209/0x660 fs/dcache.c:670 finishdput+0xc9/0x480 fs/dcache.c:879 shrinkdcacheforumount+0xa0/0x170 fs/dcache.c:1661 genericshutdownsuper+0x67/0x2c0 fs/super.c:621 killanonsuper+0x3b/0x70 fs/super.c:1289 btrfskillsuper+0x41/0x50 fs/btrfs/super.c:2127 deactivatelockedsuper+0xbc/0x130 fs/super.c:474 cleanupmnt+0x425/0x4c0 fs/namespace.c:1318 taskworkrun+0x1d4/0x260 kernel/taskwork.c:233 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0x694/0x22f0 kernel/exit.c:971 dogroup_exit+0x21c/0x2d0 kernel/exit.c:1112 __dosysexit_group kernel/exit.c:1123 [inline] __sesysexit_group kernel/exit.c:1121 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1121 x64syscall+0x2210/0x2210 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe8/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>

Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.

But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.

[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.

However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.

[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.(CVE-2026-23214)

In the Linux kernel, the following vulnerability has been resolved:

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

In the Linux kernel, the following vulnerability has been resolved:

usbip: validate numberofpackets in usbippackret_submit()

When a USB/IP client receives a RETSUBMIT response, usbippackretsubmit() unconditionally overwrites urb->numberofpackets from the network PDU. This value is subsequently used as the loop bound in usbiprecviso() and usbippadiso() to iterate over urb->isoframedesc[], a flexible array whose size was fixed at URB allocation time based on the original numberofpackets from the CMD_SUBMIT.

A malicious USB/IP server can set numberofpackets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbiprecviso() writes to urb->isoframedesc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbiprecviso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stubrx.c) and gadget side (vudcrx.c) already validate numberofpackets in the CMDSUBMIT path since commits c6688ef9f297 ("usbip: fix stubrx: harden CMDSUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudcrx: harden CMDSUBMIT path to handle malicious input"). The server side validates against USBIPMAXISOPACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original numberofpackets.

This mirrors the existing validation of actuallength against transferbufferlength in usbiprecv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbiprecviso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbippackretsubmit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIPMAXISOPACKETS limit.

Fix this by checking rpdu->numberofpackets against urb->numberofpackets in usbippackretsubmit() before the overwrite. On violation, clamp to zero so that usbiprecviso() and usbippad_iso() safely return early.(CVE-2026-31607)

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix bcackers underflow on duplicate GRPACK_MSG

The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.(CVE-2026-31662)

In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)

In the Linux kernel, the following vulnerability has been resolved:

usb: ulpi: fix double free in ulpiregisterinterface() error path

When deviceregister() fails, ulpiregister() calls put_device() on ulpi->dev.

The device release callback ulpidevrelease() drops the OF node reference and frees ulpi, but the current error path in ulpiregisterinterface() then calls kfree(ulpi) again, causing a double free.

Let putdevice() handle the cleanup through ulpidevrelease() and avoid freeing ulpi again in ulpiregister_interface().(CVE-2026-31759)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.(CVE-2026-43024)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLV_HAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix list corruption and UAF in command complete handlers

Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introduced mgmtpendingvalid(), which not only validates the pending command but also unlinks it from the pending list if it is valid. This change in semantics requires updates to several completion handlers to avoid list corruption and memory safety issues.

This patch addresses two left-over issues from the aforementioned rework:

1. In mgmtaddadvpatternsmonitorcomplete(), mgmtpendingremove() is replaced with mgmtpendingfree() in the success path. Since mgmtpendingvalid() already unlinks the command at the beginning of the function, calling mgmtpendingremove() leads to a double listdel() and subsequent list corruption/kernel panic.

2. In setmeshcomplete(), the use of mgmtpendingforeach() in the error path is removed. Since the current command is already unlinked by mgmtpendingvalid(), this foreach loop would incorrectly target other pending mesh commands, potentially freeing them while they are still being processed concurrently (leading to UAFs). The redundant mgmtcmdstatus() is also simplified to use cmd->opcode directly.(CVE-2026-43059)

In the Linux kernel, the following vulnerability has been resolved:

net: ioam6: fix OOB and missing lock

When trace->type.bit6 is set:

if (trace->type.bit6) {
    ...
    queue = skb_get_tx_queue(dev, skb);
    qdisc = rcu_dereference(queue->qdisc);

This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.

While at it, add missing lock around qdiscqstatsqlen_backlog(). The function _ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.(CVE-2026-43083)

In the Linux kernel, the following vulnerability has been resolved:

net: afkey: zero aligned sockaddr tail in PFKEY exports

PF_KEY export paths use pfkey_sockaddr_size() when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, pfkey_sockaddr_fill() initializes only the first 28 bytes of struct sockaddr_in6, leaving the final 4 aligned bytes uninitialized.

Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain skb_put():

• SADB_ACQUIRE
• SADB_X_NAT_T_NEW_MAPPING
• SADB_X_MIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkey_sockaddr_fill().(CVE-2026-43088)

In the Linux kernel, the following vulnerability has been resolved:

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.(CVE-2026-43089)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: ioam: fix potential NULL dereferences in _ioam6filltracedata()

We need to check __in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.(CVE-2026-43101)

In the Linux kernel, the following vulnerability has been resolved:

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmget_ae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.(CVE-2026-43107)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: kaweth: remove TX queue manipulation in kawethsetrx_mode

kawethsetrxmode(), the ndosetrxmode callback, calls netifstopqueue() and netifwakequeue(). These are TX queue flow control functions unrelated to RX multicast configuration.

The premature netifwakequeue() can re-enable TX while txurb is still in-flight, leading to a double usbsubmit_urb() on the same URB:

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); }

kawethsetrxmode() { netifstopqueue(); netifwake_queue(); // wakes TX queue before URB is done }

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); // URB submitted while active }

This triggers the WARN in usbsubmiturb():

"URB submitted while active"

This is a similar class of bug fixed in rtl8150 by

• commit 958baf5eaee3 ("net: usb: Remove disruptive netifwakequeue in rtl8150setmulticast").

Also kawethsetrxmode() is already functionally broken, the real setrxmode action is performed by kawethasyncsetrxmode(), which in turn is not a no-op only at ndoopen() time.(CVE-2026-43180)

In the Linux kernel, the following vulnerability has been resolved:

net: consume xmit errors of GSO frames

udpgrofrglist.sh and udpgrobench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min.

These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on.

Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's sndnxt is at sequence number N [1], but the receiver claims to have received (rcvnxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]).

In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4MSS:N-3MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCPACKUNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck.

The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this:

| GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

 x    ok    ok    <ok>|  ok    ok    ok   <x>
                      \\
           snd_nxt

"x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent.

So why did the sender not advance sndnxt even tho it clearly did send up to seg 8? tcpwrite_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above).

Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely.

We have multiple ways to fix this.

1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great.

2) fix the damn return codes We only talk about NETDEVTXOK and NETDEVTXBUSY in the documentation, so maybe we should make the return code from ndostartxmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer.

3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ipqueuexmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss?

4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQFCAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?

Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).(CVE-2026-43194)

In the Linux kernel, the following vulnerability has been resolved:

tcp: fix potential race in tcpv6synrecvsock()

Code in tcpv6synrecvsock() after the call to tcpv4synrecvsock() is done too late.

After tcpv4synrecvsock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcpv6mappedchildinit() and call this new helper from tcpv4synrecvsock() before the ehash insertion.

This allows the removal of one tcpsyncmss(), since tcpv4synrecvsock() will call it with the correct context.(CVE-2026-43198)

In the Linux kernel, the following vulnerability has been resolved:

net: Drop the lock in skbmaytx_timestamp()

skbmaytxtimestamp() may acquire sock::skcallback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU.

Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed.

Drop the lock. Use READONCE() to obtain the individual pointer. Add a matching WRITEONCE() where the pointer are cleared.(CVE-2026-43216)

In the Linux kernel, the following vulnerability has been resolved:

vhost: move vdpa group bound check to vhost_vdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)

In the Linux kernel, the following vulnerability has been resolved:

mm/pagealloc: clear page->private in freepages_prepare()

Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values.

This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swapcountcontinued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash:

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__dosysswapoff+0x1151/0x1860

Fix this by clearing page->private in freepagesprepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smpcmdpairingreq() currently builds the pairing response from the initiator authreq before enforcing the local BTSECURITYHIGH requirement. If the initiator omits SMPAUTHMITM, the response can also omit it even though the local side still requires MITM.

tkrequest() then sees an auth value without SMPAUTHMITM and may select JUSTCFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMPAUTHMITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.(CVE-2026-43334)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

The issue was discovered by the drivers/net/xdp.py selftest, more specifically the testxdpnativetxmb: - The mlx5 driver allocates a pagepool page and initializes it with a frag counter of 64 (pprefcount=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5eskbfromcqempwrqnonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpfxdppulldata() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pprefcount=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page ppref_count is 63 => negative reference counting error.

Resulting splat during the test:

WARNING: CPU: 0 PID: 188225 at ./include/net/pagepool/helpers.h:297 mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7forupstreammindebug202512081144 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] [...] Call Trace: <TASK> mlx5efreerxmpwqe+0x20a/0x250 [mlx5core] mlx5edeallocrxmpwqe+0x37/0xb0 [mlx5core] mlx5efreerxdescs+0x11a/0x170 [mlx5core] mlx5ecloserq+0x78/0xa0 [mlx5core] mlx5eclosequeues+0x46/0x2a0 [mlx5core] mlx5eclosechannel+0x24/0x90 [mlx5core] mlx5eclosechannels+0x5d/0xf0 [mlx5core] mlx5esafeswitchparams+0x2ec/0x380 [mlx5core] mlx5echangemtu+0x11d/0x490 [mlx5core] mlx5echangenicmtu+0x19/0x30 [mlx5core] netifsetmtuext+0xfc/0x240 dosetlink.isra.0+0x226/0x1100 rtnlnewlink+0x7a9/0xba0 rtnetlinkrcvmsg+0x220/0x3c0 netlinkrcvskb+0x4b/0xf0 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] _syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70

The problem applies for XDP_PASS as well which is handled in a different code path in the driver.

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag.

As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nr_frags.(CVE-2026-43465)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery

In case of a TX error CQE, a recovery flow is triggered, mlx5eresettxqsqccpc() resets dmafifocc to 0 but not dmafifopc, desyncing the DMA FIFO producer and consumer.

After recovery, the producer pushes new DMA entries at the old dmafifopc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.

The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dmafifocc is already equal to dmafifopc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched.

Remove the 'dmafifocc = 0' reset.

This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommudmaunmappage+0x79/0x90 Modules linked in: mlx5vdpa vringh vdpa bonding mlx5ib mlx5vfiopci ipip mlx5fwctl tunnel4 mlx5core ibipoib geneve ip6gre ipgre gre nftables ip6tunnel rdmaucm ibuverbs ibumad vfiopci vfiopcicore actmirred actskbedit actvlan vhostnet vhost tap ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle clsmatchall nfnetlinkcttimeout actgact clsflower schingress vhostiotlb iptableraw tunnel6 vfioiommutype1 vfio openvswitch nsh rpcsecgsskrb5 authrpcgss oidregistry xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter overlay zram zsmalloc rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm ibcore fuse [last unloaded: nftables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5forupstreammindebug202412302133 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommudmaunmap_page+0x79/0x90 ? reportbug+0x16d/0x180 ? handlebug+0x4f/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 ? iommudmaunmappage+0x2e/0x90 dmaunmappageattrs+0x10d/0x1b0 mlx5etxwidmaunmap+0xbe/0x120 [mlx5core] mlx5epolltxcq+0x16d/0x690 [mlx5core] mlx5enapipoll+0x8b/0xac0 [mlx5core] _napipoll+0x24/0x190 netrxaction+0x32a/0x3b0 ? mlx5eqcompint+0x7e/0x270 [mlx5core] ? notifiercallchain+0x35/0xa0 handlesoftirqs+0xc9/0x270 irqexitrcu+0x71/0xd0 commoninterrupt+0x7f/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40(CVE-2026-43466)

In the Linux kernel, the following vulnerability has been resolved:

ipvs: skip ipv6 extension headers for csum checks

Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.(CVE-2026-45850)

In the Linux kernel, the following vulnerability has been resolved:

apparmor: Fix & Optimize table creation from possibly unaligned memory

Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.

• Added Fixes tag
• Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access jj: remove duplicate word "convert" in comment trigger checkpatch warning

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the PASID entry.
2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dmawmb() in pasidset_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

In the Linux kernel, the following vulnerability has been resolved:

quota: fix livelock between quotactl and freeze_super

When a filesystem is frozen, quotactlblock() enters a retry loop waiting for the filesystem to thaw. It acquires sumount, checks the freeze state, drops sumount and uses sbstartwrite() - sbend_write() pair to wait for the unfreeze.

However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.

The mechanism is as follows: 1. freezesuper() sets SBFREEZEWRITE and calls sbwaitwrite(). 2. sbwaitwrite() calls percpudownwrite(), which initiates synchronizercu(). 3. Simultaneously, quotactlblock() spins in its retry loop, immediately executing the sbstartwrite() - sbendwrite() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactlblock() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronizercu() in the freezer thread waits indefinitely for the quotactlblock() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync.

This results in a hang of the freezer process and 100% CPU usage by the quota process.

While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:

# mkfs.ext4 -O quota /dev/sda 2g && mkdir amount # mount /dev/sda -o quota,usrquota,grpquota amount # taskset -c 3 bash -c "while true; do xfsfreeze -f amount; \ xfsfreeze -u amount; done" & # taskset -c 3 bash -c "while true; do quotaon amount; \ quotaoff amount; done" &

Adding condresched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronizercu() in percpudownwrite() to complete.(CVE-2026-45895)

In the Linux kernel, the following vulnerability has been resolved:

fat: avoid parent link count underflow in rmdir

Corrupted FAT images can leave a directory inode with an incorrect inlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls dropnlink(dir) and can drive inlink to 0, triggering the WARNON in drop_nlink().

Add a sanity check in vfatrmdir() and msdosrmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4putsuper() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4putsuper+0x48c/0x590 [ext4]

Tracing the failure shows that the warning fires due to an sdirtyclusterscounter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4mbmarkdiskspaceused() and the caller ext4mbnew_blocks().

First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4handledirtymetadata() call(s) made from ext4mbmarkcontext(). The changed value is non-zero at this point, so ext4mbmarkdiskspaceused() does not exit after the error bubbles up from ext4mbmarkcontext(). Instead, the former decrements both cluster counters and returns the error up to ext4mbnewblocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.

To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4mbnewblocks() is responsible for acquiring cluster reservation (via ext4claimfreeclusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
4. Fully zero out the entry only after the invalidation is complete.

Also, add a dmawmb() to contextset_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

In the Linux kernel, the following vulnerability has been resolved:

hwrng: core - use RCU and work_struct to fix race condition

Currently, hwrngfill is not cleared until the hwrngfillfn() thread exits. Since hwrngunregister() reads hwrngfill outside the rngmutex lock, a concurrent hwrngunregister() may call kthread_stop() again on the same task.

Additionally, if hwrngunregister() is called immediately after hwrngregister(), the stopped thread may have never been executed. Thus, hwrngfill remains dirty even after hwrngunregister() returns. In this case, subsequent calls to hwrngregister() will fail to start new threads, and hwrngunregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs:

refcountt: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcountwarnsaturate+0xec/0x1c0 Call Trace: kthreadstop+0x181/0x360 hwrngunregister+0x288/0x380 virtrngremove+0xe3/0x200

This patch fixes the race by protecting the global hwrngfill pointer inside the rngmutex lock, so that hwrngfillfn() thread is stopped only once, and calls to kthreadrun() and kthread_stop() are serialized with the lock held.

To avoid deadlock in hwrngfillfn() while being stopped with the lock held, we convert currentrng to RCU, so that getcurrentrng() can read currentrng without holding the lock. To remove the lock from putrng(), we also delay the actual cleanup into a work_struct.

Since getcurrentrng() no longer returns ERRPTR values, the ISERR() checks are removed from its callers.

With hwrngfill protected by the rngmutex lock, hwrngfillfn() can no longer clear hwrngfill itself. Therefore, if hwrngfillfn() returns directly after currentrng is dropped, kthreadstop() would be called on a freed taskstruct later. To fix this, hwrngfillfn() calls schedule() now to keep the task alive until being stopped. The kthreadstop() call is also moved from hwrngunregister() to dropcurrentrng(), ensuring kthreadstop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever.(CVE-2026-45949)

In the Linux kernel, the following vulnerability has been resolved:

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash.

[ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidleenterstate+0x2c4/0x668

Fix this by adding a bail-out in cpuidleselect() that returns state 0 directly when statecount <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix UMR hang in LAG error state unload

During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1].

In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive.

Fix this by adding a syserror notifier that gets registered before MLX5IBSTAGEIBREG and stays alive until after ibunregister_device(). This ensures error events reach the bond device throughout teardown.

[1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedulepreemptdisabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5ibderegmr+0x606/0x870 [mlx5ib] ? __xaerase+0x4a/0xa0 ? condresched+0x15/0x30 ? waitforcompletion+0x31/0x100 ibderegmruser+0x48/0xc0 [ibcore] ? rdmacgunchargehierarchy+0xa0/0x100 destroyhwidruobject+0x20/0x50 [ibuverbs] uverbsdestroyuobject+0x37/0x150 [ibuverbs] __uverbscleanupufile+0xda/0x140 [ibuverbs] uverbsdestroyufilehw+0x3a/0xf0 [ibuverbs] ibuverbsremoveone+0xc3/0x140 [ibuverbs] removeclientcontext+0x8b/0xd0 [ibcore] disabledevice+0x8c/0x130 [ibcore] __ibunregisterdevice+0x10d/0x180 [ibcore] ibunregisterdevice+0x21/0x30 [ibcore] __mlx5ibremove+0x1e4/0x1f0 [mlx5ib] auxiliarybusremove+0x1e/0x30 devicereleasedriverinternal+0x103/0x1f0 busremovedevice+0xf7/0x170 devicedel+0x181/0x410 mlx5rescandriverslocked.part.10+0xa9/0x1d0 [mlx5core] mlx5disablelag+0x253/0x260 [mlx5core] mlx5lagdisablechange+0x89/0xc0 [mlx5core] mlx5eswitchdisable+0x67/0xa0 [mlx5core] mlx5unload+0x15/0xd0 [mlx5core] mlx5unloadone+0x71/0xc0 [mlx5core] mlx5syncresetreloadwork+0x83/0x100 [mlx5core] processonework+0x1a7/0x360 workerthread+0x30/0x390 ? createworker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthreadflushworkfn+0x10/0x10 retfromfork+0x22/0x40(CVE-2026-45973)

In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in gfs2iomapbegin() via releasemetapath() while iomap->inlinedata still points to dibh->bdata. This causes a use-after-free when iomapwriteendinline() later attempts to write to the inline data area.

The bug sequence: 1. gfs2iomapbegin() calls gfs2metainodebuffer() to read inode metadata into dibh 2. Sets iomap->inlinedata = dibh->bdata + sizeof(struct gfs2dinode) 3. Calls releasemetapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomapwriteendinline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount with getbh() in gfs2iomapbegin(). The buffer is then properly released in gfs2iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.

agruenba: Take buffer head reference in gfs2iomapbegin() to avoid leaks in gfs2iomapget() and gfs2iomapalloc().

In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: fix u32 overflow in pushbuf reloc bounds check

nouveaugempushbufrelocapply() validates each relocation with

if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)

but relocbooffset is __u32 (uapi/drm/nouveaudrm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the sizet bo size.

Cast to u64 so the addition happens in 64-bit arithmetic.

Add Fixes: tag. - Danilo

In the Linux kernel, the following vulnerability has been resolved:

thermal: core: Fix thermal zone governor cleanup issues

If thermalzonedeviceregisterwith_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak.

In turn, thermalzonedeviceunregister() calls thermalset_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case.

Address these issues by adding two thermalsetgovernor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.(CVE-2026-46021)

In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

If loading L1's CR3 fails on a nested #VMEXIT, nestedsvmvmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nestedsvmvmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nestedsvmvmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

In the Linux kernel, the following vulnerability has been resolved:

crypto: authencesn - reject short ahash digests during instance creation

authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data.

While cryptoauthencesnsetauthsize() already rejects explicit non-zero authsizes in the range 1..3, cryptoauthencesncreate() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value.

As a result, selecting an ahash with digest size 1..3, such as cbcmac(ciphernull), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AFALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access.

Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.(CVE-2026-46033)

In the Linux kernel, the following vulnerability has been resolved:

ceph: only d_add() negative dentries when they are unhashed

Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash.

In the current VFS that is not safe. d_add() goes through __d_add() to __drehash(), which unconditionally reinserts dentry->dhash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, _dlookup() can spin forever in the hlistbl walk, typically looping only on the dname.hash mismatch check and eventually triggering RCU stall reports like this one:

rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__dlookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookupfast+0x9f/0x100 walkcomponent+0x1f/0x150 linkpathwalk+0x20e/0x3d0 pathlookupat+0x68/0x180 filenamelookup+0xdc/0x1e0 vfsstatx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __dosysnewfstatat+0x24/0x60 dosyscall64+0x6a/0x230 entrySYSCALL64afterhwframe+0x76/0x7e

This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed":

• cephfinishlookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL)

• cephlookup(): local ENOENT fast path for a complete directory with shared caps -> dadd(dentry, NULL)

Both paths can therefore re-add an already-hashed negative dentry.

Ceph already uses the correct pattern elsewhere: cephfilltrace() only calls dadd(dn, NULL) for a negative null-dentry reply when dunhashed(dn) is true.

Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is.

This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)

In the Linux kernel, the following vulnerability has been resolved:

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fbdeferrediostate. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fbinfo and the contained deferred I/O meanwhile goes away, clear struct fbdeferredio_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)

In the Linux kernel, the vlandevsetegresspriority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)

In the Linux kernel, the following vulnerability has been resolved:

eventpoll: fix ep_remove struct eventpoll / struct file UAF

epremove() (via epremovefile()) cleared file->fep under file->flock but then kept using @file inside the critical section (isfileepoll(), hlistdelrcu() through the head, spinunlock). A concurrent _fput() taking the eventpollrelease() fastpath in that window observed the transient NULL, skipped eventpollreleasefile() and ran to fop->release / filefree().

For the epoll-watches-epoll case, fop->release is epeventpollrelease() -> epclearandput() -> epfree(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlisthead is exactly where epi->fllink.pprev points, so the subsequent hlistdelrcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLABTYPESAFEBYRCU, so the slot backing @file could be recycled by allocemptyfile() -- reinitializing flock and fep -- while epremove() is still nominally inside that lock. The upshot is an attacker-controllable kmemcachefree() against the wrong slab cache.

Pin @file via epifget() at the top of epremove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds _fput() off and transitively keeps the watched struct eventpoll alive across the hlistdelrcu() and the flock use, closing both UAFs.

If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing fep, that path takes the eventpollrelease() slow path into eventpollreleasefile() and blocks on ep->mtx until the waiter side's epclearandput() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing eprefcountdecandtest() in epclearandput() cannot free the eventpoll out from under eventpollreleasefile(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpollreleasefile() on this epi, so drop the now-redundant re-check of epi->dying under flock. The cheap lockless READONCE(epi->dying) fast-path bailout stays.(CVE-2026-46242)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dclink NULL handling in HPD init amdgpudmhpdinit() may see connectors without a valid dclink. The code already checks dclink for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dclink early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c:940 amdgpudmhpdinit() error: we previously assumed 'dclink' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 */ 927 usepolling |= 928 amdgpudmconnector->dclink && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dcconnectorsupportsanalog(amdgpudmconnector->dclink->linkid.id); 930 931 dclink = amdgpudmconnector->dclink; dclink assigned here. 932 933 /* 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpdrx types aren't. IOW, amdgpuirqget/put on 937 * hpdrx isn't available. DM currently controls hpdrx 938 * explicitly with dcinterruptset() 939 */ --> 940 if (dclink->irqsourcehpd != DCIRQSOURCEINVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irqtype = dclink->irqsourcehpd - DCIRQSOURCEHPD1; 942 /* 943 * TODO: There's a mismatch between modeinfo.num_hpd 944 * and what bios reports as the # of connectors with hpd The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)