In the Linux kernel, the following vulnerability has been resolved:
net/sched: actapi: use RCU with deferred freeing for action lifecycle
When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.
Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:
0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory
This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().
Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().
Let's illustrate the new restored code path:
0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period
After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.
In the Linux kernel, the following vulnerability has been resolved:
fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal
CXL is linked before fwctl in drivers/Makefile. Both use moduleinit, so cxlpcidriverinit() runs first. When cxlpciprobe() calls fwctlregister() and then deviceadd(), fwctlclass is not yet registered because fwctlinit() hasn't run, causing classtosubsys() to return NULL and skip knodeclass initialization.
On device removal, classtosubsys() returns non-NULL, and devicedel() calls klistdel() on the uninitialized knode, triggering a NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on buildskb failure in tunxdpone()
When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.
Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rsi: fix kthread lifetime race between self-exit and external-stop
RSI driver use both self-exit(kthreadcompleteandexit) and external-stop (kthreadstop) when killing a kthread. Generally, kthreadstop() is called first, and in this case, no particular issues occur.
However, in rare instances where kthreadcompleteandexit() is called first and then kthreadstop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again.
Therefore, to prevent this with minimal modification, you must remove kthreadstop() and change the code to wait until the self-exit operation is completed.
Bluetooth: hciconn: fix potential UAF in createbigsync
In the Linux kernel, the following vulnerability has been resolved:
of: unittest: fix use-after-free in testdrvprobe()
The function testdrvprobe() retrieves the devicenode from the PCI device, applies an overlay, and then immediately calls ofnodeput(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to ofplatformdefaultpopulate(), leading to a use-after-free.
The reference to pdev->dev.ofnode is owned by the device model and should not be released by the driver. Remove the erroneous ofnodeput() to prevent premature freeing.
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix role switching during resume
If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.
The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.
So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksyswrite+0x70/0x108 arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
net: remove WARNONONCE when accessing forward path array
Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARNONONCE if userspace manages to build a sufficiently long forward path.
Remove it.
Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.
By keeping the reports private, the OSS teams can deal with the issues more on their timeline.
By making them public, they add timeline pressure and enable attackers.
Why are you making it harder on yourself? It is the opposite of what you want to do.
If it's giving CVE credit to people who've taken the time and tokens to report these issues that concerns you, than just bundle the issues in one CVE.
ROI AI
From: ROI AI <sales () roiai ca> To: "oss-security"<oss-security () lists openwall com> Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
People are shooting the messengers here. The fact is - we are going through a generational security event due to the advancement of LLMs.
It is also both trivial and extremely effective to use Agentic analysis to filter security reports.
As for 'duplicates', people are claiming this when I have seen little evidence. I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.
Moreover, if 'duplicates' are found, then that is a good signal for prioritization.
Let's stop talking about how the vulns are found and start fixing them with urgency.
ROI AI
From: Alan Coopersmith < mailto:alan.coopersmith () oracle com > To: < mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree: Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf -- -Alan Coopersmith- mailto:alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
On 4/28/26 07:58, Jeremy Stanley wrote: Other maintainers under similar floods seem to agree:
Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html
DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: Fix race bug in nvmepollirqdisable()
In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirqvector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.
To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enableirq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.
task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)
task 2: nvmeresetwork() nvmedevdisable() pdev->msixenable = 0; ...(2)
crash log:
------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 btiter+0x2fc/0x3a0 block/blk-mq-tag.c:292 sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] irqexitrcu+0xdc/0x120 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ftcm: Fix NULL pointer dereferences in nexus handling
The tpg->tpgnexus pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped.
Currently, functions like botsubmitcommand() and the data transfer paths retrieve tvnexus = tpg->tpgnexus and immediately dereference tvnexus->tvnsesess without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS).
This exposes an inconsistent API usage within the module, as peer functions like usbgsubmitcommand() and botsendbadresponse() correctly implement a NULL check for tvnexus before proceeding.
Fix this by bringing consistency to the nexus handling. Add the missing if (!tvnexus) checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system.
In the Linux kernel, the following vulnerability has been resolved:
sched/mmcid: Handle vfork()/CLONEVM correctly
Matthieu and Jiri reported stalls where a task endlessly loops in mmgetcid() when scheduling in.
It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well.
If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls.
Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read
The q54sj108a2debugfsread function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'datachar' as the source.
Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2CSMBUSBLOCKMAX + 2), this writes 30 bytes past the end of the buffer onto the stack.
Additionally, the arguments were swapped: it was reading from the zero-initialized 'datachar' and writing to 'data', resulting in all-zero output regardless of the actual I2C read.
Fix this by: 1. Expanding 'datachar' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simplereadfrombuffer call.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix in-place encryption corruption in SMB2write()
SMB2write() places write payload in iov[1..n] as part of rqiov. smb3inittransformrq() pointer-shares rqiov, so cryptmessage() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption.
The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data.
This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rqiter which gets deep-copied.
Fix by moving the write payload into rqiter via ioviterkvec(), so smb3inittransformrq() deep-copies it before encryption.
In the Linux kernel, the following vulnerability has been resolved:
drm: Account property blob allocations to memcg
DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.
Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.
Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.
SiCk <sick () afflicted sh> writes: Hi, I'm SiCk Hi, (afflicted.sh, 0xdeadbeefnetwork on GitHub).
The May 7 LWN piece on "Dirty Frag" raises the question of how the bug surfaced before Hyunwoo Kim's May 12 coordinated disclosure.
At least one of the public artifacts in circulation — my "Copy Fail 2: Electric Boogaloo" repo — is an n-day built from the public netdev fix commit, not a break from inside the embargo.
Timeline on my end: - Steffen Klassert's fix landed publicly on netdev/net.git as commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4.
Brad Spengler (@spendergrsec) publicly called the commit copyfail-class. - I read the commit, recognized the xfrm ESP-in-UDP MSGSPLICEPAGES no-COW path against shared pipe pages as an LPE primitive, and built a PoC.
- Published to GitHub and afflicted.sh on May 7. The repo credits Kim and Chen (discovery, upstream fix), Klassert (maintainer fix), Spengler (public call-out), and Theori/Xint (original Copy Fail, CVE-2026-31431) directly in the README.
I had no contact with anyone on the linux-distros embargo, no awareness of the May 12 disclosure date, and no access to Kim's write-up or PoC. The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree. Flagging this so parallel n-day work isn't characterized as a leak from inside the coordinated process. Thank you for stating this clearly. I've seen a few people confused by this and it's important to correct the record.
It's also important because it tells us a lot about how folks are quickly going from fixes -> exploits. [...] sam
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: Fix TX deadlock when using DMA
dmaengineterminateasync does not guarantee that the dmatxcomplete callback will run. The callback is currently the only place where dma->txrunning gets cleared. If the transaction is canceled and the callback never runs, then dma->txrunning will never get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear dma->txrunning after we terminate the DMA transaction. This is "safe" because serial8250txdmaflush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->txrunning is serialized.
On Mon May 4, 2026 at 6:38 PM BST, Greg KH wrote: Once it lands in Linus's tree, our role is over. I would - respectfully - disagree. To clarify, I am aware that that is the process as defined currently, but I am not sure that is the best that process could be. You asked in a previous message what could have been done better, so assuming that was meant sincerely, I'll provide some thoughts.
The first hurdle a reporter must jump through is figuring out who to actually report to - the process as defined [1] suggests it should be the maintainer first, with the security team CC'd. There is also a handy script provided to figure out the correct maintainer, and an example given.
However, the example shows the script being called with a whole load of flags (--no-l, --no-r, etc) without description. These flags are not explained, or at the very least the importance of --no-l is not stressed. As this flag excludes mailing lists from the addresses the script will give back it is, presumably, essential to use when determining who to report security issues to.
I would also disagree with the rather casual assertion of the documentation that: In the Linux kernel, all official maintainers are trusted, so the consequences of accidentally including the wrong maintainer are essentially a bit more noise for that person, i.e. nothing dramatic. Most other organisations treat security reports as strictly and absolutely need-to-know, even among trusted members of a team. Compare, for example, this stance with that of the "linux-distros" mailing list [2], which is far stronger: Aside from your participation in discussions with the reporter and on the (linux-)distros lists (including possibly continuing to CC other prior recipients of the information), the information you receive through the (linux-)distros lists must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within your distro's team except with the reporter's explicit approval, until the agreed upon public disclosure date/time or substantially complete publication by others. Neither you nor others you inform may use the information for anything other than getting the issue fixed for your distro's users and, only in rare extreme cases, for deployment of maximally non-revealing changes to maintain security of your distro's infrastructure most essential to the distro users' security in face of the security issue being dealt with. The need-to-know condition is met only if the person needs to participate in one of these two activities. The conclusion I must reach, therefore, is it would be more secure if the process were simplified to all requests going to the security team address only, who then take responsibility for triaging and engaging the appropriate people.
The submission process also places an extra-ordinarily high burden on the reporter, rather than the security team itself, to coordinate an appropriate response to bugs. As the process makes clear, the choice of when - or indeed if - to even inform linux-distros of an issue is left entirely up to the reporter, with a recommendation that they not be told at all until a fix is ready. It is, presumably, also the reporter's responsibility to monitor for a fix becoming ready.
The process also states: DO NOT contact the "linux-distros" mailing list UNTIL... you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community. Which is about as ominous and off-putting a statement that it would turn many organisations away from meaningfully engaging in the process at all.
The process also suggests that a CVE won't even be assigned for an issue unless the reporter - once again - takes the initiative for requesting one: If a reporter wishes to have a CVE identifier assigned for a confirmed issue, they can contact the kernel CVE assignment team to obtain one. None of this is normal - why the Linux security team and CNA team even talking amongst themselves internally? Why is it an external party's job to coordinate that? The reality is the team best suited to knowing how, and being subtly trustworthy, to co-ordinate security responses is almost always the team within the project itself, not the good Samaritan who did the reporting.
Finally the CVEs themselves; their descriptions are - frankly - appalling. The CVE description in this case was: In the Linux kernel, the following vulnerability has been resolved:
crypto: algifaead - Revert to operating out-of-place
This mostly reverts commit 72548b093ee3 except for the copying of the associated data.
There is no benefit in operating in-place in algifaead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. This tells a user nothing. What is the threat? Don't know. When does it occur? Dunno. What impact did it have? shrugs. While I understand the potential need to be vague in the commit message of the fix itself to avoid drawing attention to it prior to the publication of the CVE, once we get to CVE stage the whole point is surely to be informative about the threat, who it effects, and how to mitigate against it. Compare any Linux CVE description with those raised by other CNAs and Linux's come up wanting every time.
Ultimately, none of these points are theoretical. While I am frustrated with the reporters for not following the process as defined in this case, which has led to a pretty disastrous disclosure all round, the result is a prime example of what was always going to happen sooner or later with a disclosure process so opaque and seemingly hostile.
At the end of the day I am aware that Linux is an open source project, and is maintained by volunteers, and I am therefore in no position to say what MUST [3] - or even what SHOULD - be done. Given you did ask for what could be better, however, I have given my thoughts, and I can observe that the process that we have today is not a particularly strong one.
[1]: https://docs.kernel.org/process/security-bugs.html [2]: https://oss-security.openwall.org/wiki/mailing-lists/distros [3]: https://www.rfc-editor.org/rfc/rfc2119
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: fuac1legacy: validate control request size
faudiocomplete() copies req->length bytes into a 4-byte stack variable:
u32 data = 0; memcpy(&data, req->buf, req->length);
req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write.
Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data.
This avoids copying a host-influenced length into a fixed-size stack object.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix constant blinding for PROBEMEM32 stores
BPFST | BPFPROBEMEM32 immediate stores are not handled by bpfjitblindinsn(), allowing user-controlled 32-bit immediates to survive unblinded into JIT-compiled native code when bpfjitharden >= 1.
The root cause is that convertctxaccesses() rewrites BPFST|BPFMEM to BPFST|BPFPROBEMEM32 for arena pointer stores during verification, before bpfjitblindconstants() runs during JIT compilation. The blinding switch only matches BPFST|BPFMEM (mode 0x60), not BPFST|BPFPROBEMEM32 (mode 0xa0). The instruction falls through unblinded.
Add BPFST|BPFPROBEMEM32 cases to bpfjitblindinsn() alongside the existing BPFST|BPFMEM cases. The blinding transformation is identical: load the blinded immediate into BPFREGAX via mov+xor, then convert the immediate store to a register store (BPFSTX).
The rewritten STX instruction must preserve the BPFPROBEMEM32 mode so the architecture JIT emits the correct arena addressing (R12-based on x86-64). Cannot use the BPFSTXMEM() macro here because it hardcodes BPFMEM mode; construct the instruction directly instead.
On a system exposing an NVMe/TCP target, a remote client can trigger a kernel panic by sending a CONNECT command for an I/O queue with a bogus or stale CNTLID.
An attacker with network access to the NVMe/TCP target can trigger an unauthenticated Denial of Service condition on the affected machine.
This vulnerability allows local attackers to disclose sensitive information on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 3.8. The following CVEs are assigned: CVE-2022-1972.
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix NULL pointer dereference in icevsisetnapiqueues
Add NULL pointer checks in icevsisetnapiqueues() to prevent crashes during resume from suspend when rings[qidx]->qvector is NULL.
Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]
SR-IOV state: both disabled and enabled can reproduce this issue.
kernel version: v6.18
Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake.
Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: errorcode(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netifqueuesetnapi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <TASK> <4>[ 231.452996] ? icevsisetnapiqueues+0x4d/0x110 [ice] <4>[ 231.453482] iceresume+0xfd/0x220 [ice] <4>[ 231.453977] ? pfxpcipmresume+0x10/0x10 <4>[ 231.454425] pcipmresume+0x8c/0x140 <4>[ 231.454872] ? pfxpcipmresume+0x10/0x10 <4>[ 231.455347] dpmruncallback+0x5f/0x160 <4>[ 231.455796] ? dpmwaitforsuperior+0x107/0x170 <4>[ 231.456244] deviceresume+0x177/0x270 <4>[ 231.456708] dpmresume+0x209/0x2f0 <4>[ 231.457151] dpmresumeend+0x15/0x30 <4>[ 231.457596] suspenddevicesandenter+0x1da/0x2b0 <4>[ 231.458054] enterstate+0x10e/0x570
Add defensive checks for both the ring pointer and its qvector before dereferencing, allowing the system to resume successfully even when qvectors are unmapped.
In the Linux kernel, the following vulnerability has been resolved:
net: 3com: 3c59x: fix possible null dereference in vortexprobe1()
pdev can be null and freering: can be called in 1297 with a null pdev.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix buffer validation by including null terminator size in EA length
The smb2setea function, which handles Extended Attributes (EA), was performing buffer validation checks that incorrectly omitted the size of the null terminating character (+1 byte) for EA Name. This patch fixes the issue by explicitly adding '+ 1' to EaNameLength where the null terminator is expected to be present in the buffer, ensuring the validation accurately reflects the total required buffer size.
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid possible NULL deref in skbclone()
syzbot got a crash [1] in skbclone(), caused by a bug in hsrgetuntaggedframe().
When/if createstrippedskbhsr() returns NULL, we must not attempt to call skbclone().
While we are at it, replace a WARNONCE() by netdevwarnonce().
[1] general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 RIP: 0010:skbclone+0x108/0x3c0 net/core/skbuff.c:1641 Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00 RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000 RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000 RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140 R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640 R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620 FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> hsrgetuntaggedframe+0x4e/0x610 net/hsr/hsrforward.c:164 hsrforwarddo net/hsr/hsrforward.c:461 [inline] hsrforwardskb+0xcca/0x1d50 net/hsr/hsrforward.c:623 hsrhandleframe+0x588/0x7c0 net/hsr/hsrslave.c:69 netifreceiveskbcore+0x9fe/0x38f0 net/core/dev.c:5379 netifreceiveskbonecore+0xae/0x180 net/core/dev.c:5483 netifreceiveskb+0x1f/0x1c0 net/core/dev.c:5599 netifreceiveskbinternal net/core/dev.c:5685 [inline] netifreceiveskb+0x12f/0x8d0 net/core/dev.c:5744 tunrxbatched+0x4ab/0x7a0 drivers/net/tun.c:1544 tungetuser+0x2686/0x3a00 drivers/net/tun.c:1995 tunchrwriteiter+0xdb/0x200 drivers/net/tun.c:2025 callwriteiter include/linux/fs.h:2187 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x9e9/0xdd0 fs/readwrite.c:584 ksyswrite+0x127/0x250 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
In the Linux kernel, the following vulnerability has been resolved:
nfp: clean mc addresses in application firmware when closing port
When moving devices from one namespace to another, mc addresses are cleaned in software while not removed from application firmware. Thus the mc addresses are remained and will cause resource leak.
Now use devmcunsync to clean mc addresses when closing port.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add preemptcount{sub,add} into btf id deny list
The recursion check in bpfprogenter and bpfprogexit leave preemptcount{sub,add} unprotected. When attaching trampoline to them we get panic as follows,
[ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28) [ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI [ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4 [ 867.843100] Call Trace: [ 867.843101] <TASK> [ 867.843104] asmexcint3+0x3a/0x40 [ 867.843108] RIP: 0010:preemptcountsub+0x1/0xa0 [ 867.843135] bpfprogenterrecur+0x17/0x90 [ 867.843148] bpftrampoline64424681080+0x2e/0x1000 [ 867.843154] ? preemptcountsub+0x1/0xa0 [ 867.843157] preemptcountsub+0x5/0xa0 [ 867.843159] ? migrateenable+0xac/0xf0 [ 867.843164] bpfprogexitrecur+0x2d/0x40 [ 867.843168] bpftrampoline64424681080+0x55/0x1000 ... [ 867.843788] preemptcountsub+0x5/0xa0 [ 867.843793] ? migrateenable+0xac/0xf0 [ 867.843829] bpfprogexitrecur+0x2d/0x40 [ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35) [ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c) [ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec) [ 867.843842] bpftrampoline64424681080+0x55/0x1000 ...
That is because in bpfprogexitrecur, the preemptcount{sub,add} are called after prog->active is decreased.
Fixing this by adding these two functions into btf ids deny list.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Use skdstget() and dstdevrcu() in mptcpactiveenable().
mptcpactiveenable() is called from subflowfinishconnect(), which is icsk->icskafops->skrxdstset() and it's not always under RCU.
Using skdstget(sk)->dev could trigger UAF.
Let's use skdstget() and dstdevrcu().