dm cache: fix dirty mapping checking in passthrough mode switching

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

iommu/riscv: Add IOTINVAL after updating DDT/PDT entries

Add riscviommuiodiriotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2).

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function pppinput() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both pppgeneric.c and pppoe.c to avoid open-coding.

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

net/sched: netem: fix queue limit check to include reordered packets

The queue limit check in netemenqueue() uses q->tlen which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (qdiscenqueuehead) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering.

Include sch->q.qlen in the limit check.

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

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

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

nfc: hci: shdlc: Stop timers and work before freeing context

llcshdlcdeinit() purges SHDLC skb queues and frees the llcshdlc structure while its timers and state machine work may still be active.

Timer callbacks can schedule smwork, and smwork accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races.

Stop all SHDLC timers and cancel smwork synchronously before purging the queues and freeing the context.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

drm/amdgpu/sdma4: replace BUGON with WARNON in fence emission

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

RDMA/hns: Fix unlocked call to hnsroceqpremove()

Sashiko points out that hnsroceqpremove() requires the caller to hold locks. The error flow in hnsrocecreateqpcommon() 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:

usb: ulpi: fix memory leak on ulpiregister() error paths

Commit 01af542392b5 ("usb: ulpi: fix double free in ulpiregisterinterface() error path") removed kfree(ulpi) from ulpiregisterinterface() to fix a double-free when deviceregister() fails.

But when ulpiofregister() or ulpireadid() fail before deviceregister() 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:

selinux: use sk blob accessor in socket permission helpers

SELinux socket state lives in the composite LSM socket blob.

sockhasperm() and nlmsgsockhasextendedperms() currently dereference sk->sksecurity 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 selinuxsock() instead of accessing sk->sksecurity directly.

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

hwmon: (pt5161l) Fix bugs in pt5161lreadblockdata()

Fix two bugs in pt5161lreadblockdata():

1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2csmbusreadblockdata() can return up to I2CSMBUSBLOCKMAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2CSMBUSBLOCKMAX.

2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2csmbusreadblockdata() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

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

serial: caif: fix use-after-free in caifserial ldiscclose()

There is a use-after-free bug in caifserial where handletx() may access ser->tty after the tty has been freed.

The race condition occurs between ldiscclose() and packet transmission:

CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldiscclose() ttykrefput(ser->tty) [tty may be freed here] <-- race window --> caifxmit() handletx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedulework() serrelease() unregisternetdevice()

The root cause is that ttykrefput() is called in ldiscclose() while the network device is still active and can receive packets.

Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldiscopen and freed in serrelease via unregisternetdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to serrelease() where the network device is unregistered.

Fix this by moving ttykrefput() from ldiscclose() to serrelease(), after unregisternetdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF.

Note: We save ser->tty before unregisternetdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needsfreenetdev = true).

How to reproduce: Add mdelay(500) at the beginning of ldiscclose() to widen the race window, then run the reproducer program [1].

Note: There is a separate deadloop issue in handletx() when using PORTUNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uartwriteroom() and uartwrite() in serial core. It has been addressed in a separate patch [2].

KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in handletx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caifuaftrigge/9929

Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xd0/0x630 kasanreport+0xe4/0x120 handletx+0x5d1/0x620 devhardstartxmit+0x9d/0x6c0 devqueuexmit+0x6e2/0x4410 packetxmit+0x243/0x360 packetsendmsg+0x26cf/0x5500 syssendto+0x4a3/0x520 x64syssendto+0xe0/0x1c0 dosyscall64+0xc9/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7

Allocated by task 9930:

Freed by task 64:

Last potentially related work creation:

The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)

The buggy address belongs to the physical page: pageowner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace:

Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u

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

crypto: inside-secure/eip93 - unregister only available algorithm

EIP93 has an options register. This register indicates which crypto algorithms are implemented in silicon. Supported algorithms are registered on this basis. Unregister algorithms on the same basis. Currently, all algorithms are unregistered, even those not supported by HW. This results in panic on platforms that don't have all options implemented in silicon.

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

drm/panthor: Fix NULL pointer dereference on panthorfwunplug

This patch removes the MCU halt and wait for halt procedures during panthorfwunplug() as the MCU can be in a variety of states or the FW may not even be loaded/initialized at all, the latter of which can lead to a NULL pointer dereference.

It should be safe on unplug to just disable the MCU without waiting for it to halt as it may not be able to.

Hi Salvatore, all,

On Fri, May 15, 2026 at 07:12:08AM +0200, Salvatore Bonaccorso wrote: I'm not 100% certain, but setting restrictive kernel.yama.ptracescope might as well serve as temporary workaround. Can you confirm? Excellent question, thank you very much! We have just now tried, and setting /proc/sys/kernel/yama/ptracescope to 2 (admin-only attach) or 3 (no attach) does in fact protect against all the exploits that we know of (but in theory at least other exploitation methods might exist).

Thanks again! With best regards,

-- the Qualys Security Advisory team

The traditional vulnerability disclosure timeline relies on a fundamental assumption: exploit development and vulnerability discovery take time. Over the last 12 months the integration of LLMs into offensive tooling has demonstrably broken this assumption. I recently published a technical write-up arguing that the 90-day disclosure window is effectively dead backed by three specific observations from recent incidents:

1. Automated Diff Analysis (30-minute n-days) : The safety net between a patch release and an in-the-wild exploit is gone. Taking a recent React security patch (CVE-2026-23870), I used an LLM to analyze the diff, identify the vulnerable path, and write a working DoS PoC in roughly 30 minutes. The human reverse-engineering bottleneck has been bypassed. 2. Vulnerability Convergence : I recently reported a critical P0 to a vendor and was told I was the 11th reporter in 6 weeks. LLM assisted scanners are causing independent researchers to converge on the same bugs simultaneously. An embargo no longer contains the vulnerability; it simply provides a head start to whichever threat actor also found it. 3. The Linux Kernel (Copy Fail & Dirty Frag) : The recent kernel exploits highlight this perfectly. Copy Fail (CVE-2026-31431) went from an automated AI scan to a public PoC to nation state weaponization in days. Shortly after the embargo for Dirty Frag (CVE-2026-43284 / CVE-2026-43500) was broken in hours because an unrelated third party independently discovered the same bug class using similar tooling.

The defense cannot operate on monthly cycles when the offense is operating in hours. The focus needs to shift to real-time, PR-level AI scanning to match the pace. can read the full technical breakdown and case studies on my blog:https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/

I am curious if the researchers here are experiencing similar convergence rates or if you view this as a temporary anomaly while legacy codebases are scanned with new tools.

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 pprefcount 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 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x240 syssendmsg+0x7c/0xb0 [...] syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70

The problem applies for XDPPASS 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 XDPPASS). 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 nrfrags.

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

drm/xe/sync: Cleanup partially initialized sync on parse failure

xesyncentryparse() can allocate references (syncobj, fence, chain fence, or user fence) before hitting a later failure path. Several of those paths returned directly, leaving partially initialized state and leaking refs.

Route these error paths through a common freesync label and call xesyncentrycleanup(sync) before returning the error.

(cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)

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

f2fs: fix to avoid uninit-value access in f2fssanitychecknodefooter

syzbot reported a f2fs bug as below:

BUG: KMSAN: uninit-value in f2fssanitychecknodefooter+0x374/0xa20 fs/f2fs/node.c:1520 f2fssanitychecknodefooter+0x374/0xa20 fs/f2fs/node.c:1520 f2fsfinishreadbio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fsreadendio+0x6ab/0x2220 fs/f2fs/data.c:-1 bioendio+0x1006/0x1160 block/bio.c:1792 submitbionoacct+0x533/0x2960 block/blk-core.c:891 submitbio+0x57a/0x620 block/blk-core.c:926 blkcryptosubmitbio include/linux/blk-crypto.h:203 [inline] f2fssubmitreadbio+0x12c/0x360 fs/f2fs/data.c:557 f2fssubmitpagebio+0xee2/0x1450 fs/f2fs/data.c:775 readnodefolio+0x384/0x4b0 fs/f2fs/node.c:1481 getnodefolio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fsgetinodefolio+0x40/0x50 fs/f2fs/node.c:1623 doreadinode fs/f2fs/inode.c:425 [inline] f2fsiget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fsfillsuper+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 gettreebdevflags+0x6e6/0x920 fs/super.c:1694 gettreebdev+0x38/0x50 fs/super.c:1717 f2fsgettree+0x35/0x40 fs/f2fs/super.c:5436 vfsgettree+0xb3/0x5d0 fs/super.c:1754 fcmount fs/namespace.c:1193 [inline] donewmountfc fs/namespace.c:3763 [inline] donewmount+0x885/0x1dd0 fs/namespace.c:3839 pathmount+0x7a2/0x20b0 fs/namespace.c:4159 domount fs/namespace.c:4172 [inline] dosysmount fs/namespace.c:4361 [inline] sesysmount+0x704/0x7f0 fs/namespace.c:4338 x64sysmount+0xe4/0x150 fs/namespace.c:4338 x64syscall+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls64.h:166 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x134/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The root cause is: in f2fsfinishreadbio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue.

The “Dirty Frag” vulnerability is a chained local privilege escalation (LPE) issue in the Linux kernel that combines flaws in the ESP/XFRM and RXRPC subsystems to allow an unprivileged local attacker to gain root access on major Linux distributions. The attack abuses kernel page-cache manipulation and network protocol handling to overwrite privileged binaries and execute arbitrary code with elevated privileges. Exploitation differs by distribution: the ESP issue affects systems permitting unprivileged user namespaces, while the RXRPC issue impacts distributions with RXRPC enabled, such as Ubuntu. Together, the vulnerabilities provide broad cross-distribution root compromise capability, with mitigations involving disabling vulnerable kernel modules (esp4, esp6, and rxrpc) until upstream patches are fully merged and deployed.

Solar Designer <solar () openwall com> writes: Hi,

V3rdant, CC'ed here, brought this Linux kernel issue to linux-distros on March 18, and apparently also to s@k.o at about the same time, citing the (outdated) syzkaller "Reporting Linux kernel bugs" instructions:

https://www.openwall.com/lists/oss-security/2026/05/03/2

So we immediately had a coordination problem, which V3rdant acknowledged:

On Wed, Mar 18, 2026 at 10:28:23PM +0000, x xw wrote: [...] It looks like literally everyone dropped the ball on this issue after that point. This includes two distros who had volunteered for:

https://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-back

9. Stay on top of issues to ensure progress is being made, remind others when there's no apparent progress, as well as when the public disclosure date for an issue is approaching and when it's finally reached (unless the reporter beats you to it by making their mandatory posting to oss-security first) - primary: Gentoo, backup: Amazon

I since heard back from Gentoo on this, but no word from Amazon yet. Indeed. I do think there's a circular element here, which does not excuse the ball being dropped, but I offer it as a partial explanation: the current kernel process makes it challenging to keep track of whether a fix is actually in-flight or whether it's related to a reported problem. But nonetheless, we should've stayed on top of it with the reporter.

We're also onboarding another member for the security team as it's just myself at the moment, and we unexpectedly lost another from illness recently. [...] sam

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

EFI/CPER: don't dump the entire memory region

The current logic at cperprintfwerr() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory.

The end result can be:

- the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region.

Fix it by checking if the section length is too small before doing a hex dump.

[ rjw: Subject tweaks ]

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

dlm: validate length in dlmsearchrsbtree

The len parameter in dlmdumprsbname() is not validated and comes from network messages. When it exceeds DLMRESNAMEMAXLEN, it can cause out-of-bounds write in dlmsearchrsbtree().

Add length validation to prevent potential buffer overflow.

From the admin side, here are my concerns. LDPRELOAD and capabilities are not a great option due to user namespaces, lsm limitations, etc....

Review this qualys submission from last year for an example. https://www.openwall.com/lists/oss-security/2025/03/27/6

You should expect any UID (even nobody) to be able to gain the privileges in their bounding set, and because some packages like LXD remove some of the protections from above etc...

Note the Bounding set on the install user on Ubuntu 26.04:

$ cat /proc/$$/status | grep ^CapBnd CapBnd: 000001ffffffffff $ capsh --decode=000001ffffffffff 0x000001ffffffffff=capchown,capdacoverride,capdacreadsearch,capfowner,capfsetid,capkill,capsetgid,capsetuid,capsetpcap,caplinuximmutable,capnetbindservice,capnetbroadcast,capnetadmin,capnetraw,capipclock,capipcowner,capsysmodule,capsysrawio,capsyschroot,capsysptrace,capsyspacct,capsysadmin,capsysboot,capsysnice,capsysresource,capsystime,capsysttyconfig,capmknod,caplease,capauditwrite,capauditcontrol,capsetfcap,capmacoverride,capmacadmin,capsyslog,capwakealarm,capblocksuspend,capauditread,capperfmon,capbpf,capcheckpointrestore

Both socket(2) and socket(3p) define and allow for EACESS, IMHO it would be far more maintainable to leverage credentials(7) vs capabilities(7) in this case, and it may offer a backwards compatible solution.

I am not talking about requiring a device file with permissions, just a method of setting constraints based on uid/gid etc... Especially as these mechanisms often could never justify namespace support, I think it cannot depend on the permissions of a device file as they may not be able to view it.

I am sure that there is a reason no one has taken advantage of: https://man7.org/linux/man-pages/man3/socket.3p.html The socket() function may fail if:

EACCES The process does not have appropriate privileges.

Or: https://man7.org/linux/man-pages/man2/socket.2.html EACCES Permission to create a socket of the specified type and/or protocol is denied.

IMHO, ideally the kernel would provide a (ideally subuid/subgid compatible) method of limiting PF/AF sockets outside of the core. Right now it is almost impossible to run with reduced privileges, and in the oci/k8s world there are no methods to enforce even syscomp rules, because the commands/containers/upstream don't allow for a bounding set. The CRIs like runc or crun for example can be invoked directly, and as mutation etc... is up stream they will accept any seccomp profile or no profile at all,

Currently it is trivial to gain almost any capability in a users bounding set, and while userns limits the scope to the user, if you are gating on capabilities(), you should expect any adversarial code (browser plugin, container image etc..) to be able to gain it.

IMHO finding someway to depend on credentials(7) is a far more maintainable step: https://man7.org/linux/man-pages/man7/credentials.7.html

I realize that this isn't an option for AFINET, etc... but those have namespace support, it would seem that the cost for checking uid/gid before doing file descriptor allocation /proc//fd in cases like this would be easier.

This doesn't solve the splice() issue, but would allow us admins to harden our systems and as EAFNOSUPPORT and EACCES are existing standards, returning EACCES isn't a huge change.

On Sat, May 2, 2026 at 7:56 AM Demi Marie Obenour <demiobenour () gmail com> wrote: On 5/1/26 23:54, Eric Biggers wrote: On Sat, May 02, 2026 at 03:35:58AM +0000, Eric Biggers wrote: So the idea would be something along the lines of: And just to make sure no one gets the wrong impression: just because there seem to be ways in which the attack surface of AFALG could/should be reduced doesn't mean that userspace should keep using it (or even worse, start to use it). Fixing programs like iwd needs to proceed concurrently, so that eventually (some years down the line) the problem can finally be fully solved by removing AFALG from the kernel source.

- Eric Can AFALG be emulated using LDPRELOAD? That would allow it to be eliminated from the kernel much more quickly, as one would not need to get rid of all of its existing users. It would even work for those who need AFALG because of closed source binaries, who otherwise will have no alternative other than running an old kernel in a VM. -- Sincerely, Demi Marie Obenour (she/her/hers)

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

crypto: caam - fix DMA corruption on long hmac keys

When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory.

The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy.

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

net: macb: properly unregister fixed rate clocks

The additional resources allocated with clkregisterfixedrate() need to be released with clkunregisterfixedrate(), otherwise they are lost.

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

auxdisplay: line-display: fix NULL dereference in linedisprelease

linedisprelease() currently retrieves the enclosing struct linedisp via tolinedisp(). That lookup depends on the attachment list, but the attachment may already have been removed before putdevice() invokes the release callback. This can happen in linedispunregister(), and can also be reached from some linedispregister() error paths.

In that case, tolinedisp() returns NULL and linedisprelease() dereferences it while freeing the display resources.

The struct device released here is the embedded linedisp->dev used by linedispregister(), so retrieve the enclosing object directly with containerof() instead.

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 setchmoddacl() past the validated extent while they compare or copy attacker-controlled ACEs.

Factor the DACL structural checks into validatedacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parsedacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.

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

xfrm: iptfs: fix skbput() panic on non-linear skb during reassembly

In iptfsreassemcont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear.

When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skbput() to append the data and as newskb is non-linear it triggers SKBLINEARASSERT check.

Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skbput+0x3c/0x40 [...] Call Trace: <IRQ> iptfsreassemcont+0x1ab/0x5e0 [xfrmiptfs] iptfsinputordered+0x2af/0x380 [xfrmiptfs] iptfsinput+0x122/0x3e0 [xfrmiptfs] xfrminput+0x91e/0x1a50 xfrm4esprcv+0x3a/0x110 ipprotocoldeliverrcu+0x1d7/0x1f0 iplocaldeliverfinish+0xbe/0x1e0 netifreceiveskbcore.constprop.0+0xb56/0x1120 netifreceiveskblistcore+0x133/0x2b0 netifreceiveskblistinternal+0x1ff/0x3f0 napicompletedone+0x81/0x220 virtnetpoll+0x9d6/0x116e [virtionet] napipoll.constprop.0+0x2b/0x270 netrxaction+0x162/0x360 handlesoftirqs+0xdc/0x510 irqexitrcu+0xe7/0x110 irqexitrcu+0xe/0x20 commoninterrupt+0x85/0xa0 </IRQ> <TASK>

Fix this by checking if the skb is non-linear. If it is, linearize it by calling skblinearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it.