Where
-Infinity
0
Severity
7.3
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H/E:U

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

ipv6: use RCU in ip6output()

Use RCU in ip6output() in order to use dstdevrcu() to prevent possible UAF.

We can remove rcureadlock()/rcureadunlock() pairs from ip6finishoutput2().

1 / 4
Source: Red Hat
First published (updated )
Severity
7.3
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U

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

net: use dstdevrcu() in sksetupcaps()

Use RCU to protect accesses to dst->dev from sksetupcaps() and skdstgsomaxsize().

Also use dstdevrcu() in ip6dstmtumaybeforward(), and ipdstmtumaybeforward().

ip4dsthoplimit() can use dstdevnetrcu().

1 / 5
Source: Red Hat
First published (updated )
Severity
2
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

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

1 / 6
Source: Launchpad
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

bpf: avoid holding freezemutex during mmap operation

1 / 4
Source: Microsoft
First published (updated )
Severity
8.1
EPSS
0.04%
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftphandle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.

1 / 2
Source: MITRE
First published (updated )
Severity
4.1
Null Pointer Dereference
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

usb: typec: ucsi: displayport: Fix NULL pointer access

This patch ensures that the UCSI driver waits for all pending tasks in the ucsidisplayportwork workqueue to finish executing before proceeding with the partner removal.

1 / 3
Source: IBM
First published (updated )
Severity
7.8
Race Condition, Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

wifi: rtlwifi: remove unused checkbuddypriv

Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures.

Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, checkbuddypriv to find the private data from a similar device.

However, that function was never used.

Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory.

Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.

1 / 3
Source: Red Hat
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.

1 / 5
Source: NVD
First published (updated )
Severity
5.5
Buffer Overflow, SQL Injection
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

In SQLite before 3.32.3 select.c mishandles query-flattener optimization leading to a multiSelectOrderBy heap overflow because of misuse of transitive properties for constant propagation.

1 / 8
Source: Microsoft
First published (updated )
Severity
7.3
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In multiple functions of eventpoll.c, there is a possible use after free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

1 / 5
Source: OSV
First published (updated )
Severity
7.3
Use After Free, Race Condition
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

ALSA: aloop: Fix racy access at PCM trigger

1 / 5
Source: Microsoft
First published (updated )
Severity
8.3
Use After Free, Race Condition
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

scsi: target: iscsi: Fix use-after-free in iscsitdecsessionusagecount()

In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsitsession structure immediately.

This creates a race condition where the current thread may attempt to execute spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.

To resolve this, release the sessionusagelock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.

1 / 4
Source: Red Hat
First published (updated )
Severity
4.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

vsock/vmci: Clear the vmci transport packet properly when initializing it

In vmcitransportpacketinit memset the vmcitransportpacket before populating the fields to avoid any uninitialised data being left in the structure.

1 / 4
Source: NVD
First published (updated )
Severity
9.2
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUELIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rpbuflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.

1 / 3
Source: IBM
First published (updated )
Severity
7.3
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U

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

ipv6: use RCU in ip6xmit()

Use RCU in ip6xmit() in order to use dstdevrcu() to prevent possible UAF.

1 / 4
Source: Red Hat
First published (updated )
Severity
6.9
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

1 / 4
Source: Red Hat
First published (updated )
Severity
7.5
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

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

NFSv4/pNFS: Clear NFSINOLAYOUTCOMMIT in pnfsmarklayoutstateidinvalid

Fixes a crash when layout is null during this call stack:

writeinode - nfs4writeinode - pnfslayoutcommitinode

pnfssetlayoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFSINOLAYOUTCOMMIT otherwise we might attempt to reference a null layout.

1 / 4
Source: IBM
First published (updated )
Severity
7.3
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

fbdev: Add bounds checking in bitputcs to fix vmalloc-out-of-bounds

1 / 3
Source: Microsoft
First published (updated )
Severity
7.3
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

bonding: fix use-after-free due to enslave fail after slave array update

1 / 5
Source: Microsoft
First published (updated )
Severity
8.7
EPSS
0.03%
Null Pointer Dereference
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec

Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2CDATA PDUs.

The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2CDATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.

Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2CDATA PDU for uninitialized command slot → both pointers NULL

The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated

1 / 5
Source: Red Hat
First published (updated )
Severity
8.5
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

net/sched: Only allow actct to bind to clsact/ingress qdiscs and shared blocks

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."

actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach actct to egress (albeit only with clsact).

[1]

1 / 4
Source: IBM
First published (updated )
Severity
7.3
Use After Free
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H

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

vsock: Ignore signal/timeout on connect() if already established

During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues:

1. connect() invoking vsocktransportcancelpkt() - virtiotransportpurgeskbs() may race with sendmsg() invoking virtiotransportgetcredit(). This results in a permanently elevated vvs-bytesunsent. Which, in turn, confuses the SOCKLINGER handling.

2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.

3. connect() transitioning SSCONNECTED - SSUNCONNECTED allows for a transport change/drop after TCPESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.

Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg().

[1]:

1 / 4
Source: IBM
First published (updated )
Severity
7
Buffer Overflow
AV:P/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

ALSA: usb-audio: Fix potential overflow of PCM transfer buffer

1 / 4
Source: Microsoft
First published (updated )
Severity
7.3
Use After Free
AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:H

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

smc: Fix use-after-free in pnetfindbasendev().

syzbot reported use-after-free of netdevice in pnetfindbasendev(), which was called during connect(). [0]

smcpnetfindismresource() fetches skdstget(sk)->dev and passes down to pnetfindbasendev(), where RTNL is held. Then, UAF happened at pnetfindbasendev() when the dev is first used.

This means dev had already been freed before acquiring RTNL in pnetfindbasendev().

While dev is going away, dst->dev could be swapped with blackholenetdev, and the dev's refcnt by dst will be released.

We must hold dev's refcnt before calling smcpnetfindismresource().

Also, smcpnetfindroceresource() has the same problem.

Let's use skdstget() and dstdevrcu() in the two functions.

[0]: BUG: KASAN: use-after-free in pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609

CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 pnetfindbasendev net/smc/smcpnet.c:946 [inline] smcpnetfindismbypnetid net/smc/smcpnet.c:1103 [inline] smcpnetfindismresource+0xef/0x390 net/smc/smcpnet.c:1154 smcfindismdevice net/smc/afsmc.c:1030 [inline] smcfindproposaldevices net/smc/afsmc.c:1115 [inline] smcconnect+0x372/0x1890 net/smc/afsmc.c:1545 smcconnect+0x877/0xd90 net/smc/afsmc.c:1715 sysconnectfile net/socket.c:2086 [inline] sysconnect+0x313/0x440 net/socket.c:2105 dosysconnect net/socket.c:2111 [inline] sesysconnect net/socket.c:2108 [inline] x64sysconnect+0x7a/0x90 net/socket.c:2108 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfpmask 0x446dc0(GFPKERNELACCOUNT|GFPZERO|GFPNOWARN|GFPRETRYMAYFAIL|GFPCOMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, freets 380670750466 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x240/0x2a0 mm/pagealloc.c:1851 prepnewpage mm/pagealloc.c:1859 [inline] getpagefromfreelist+0x21e4/0x22c0 mm/pagealloc.c:3858 allocfrozenpagesnoprof+0x181/0x370 mm/pagealloc.c:5148 allocpagesmpol+0x232/0x4a0 mm/mempolicy.c:2416 kmalloclargenode+0x5f/0x1b0 mm/slub.c:4317 kmalloclargenodenoprof+0x18/0x90 mm/slub.c:4348 dokmallocnode mm/slub.c:4364 [inline] kvmallocnode ---truncated---

1 / 5
Source: Red Hat
First published (updated )
Severity
8.6
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H/E:U

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

sctp: avoid NULL dereference when chunk data buffer is missing

chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.

chunk->skb can only be NULL if chunk->headskb is not. Check for fraglist instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.

1 / 4
Source: Red Hat
First published (updated )
Severity
8.5
Use After Free
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

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

net: atm: fix /proc/net/atm/lec handling

/proc/net/atm/lec must ensure safety against devlec[] changes.

It appears it had devput() calls without prior devhold(), leading to imbalance and UAF.

1 / 4
Source: Red Hat
First published (updated )
Severity
7.8
Double Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

exfat: fix double free in delayedfree

The double free could happen in the following path.

exfatcreateupcasetable() exfatcreateupcasetable() : return error exfatfreeupcasetable() : free ->volutbl exfatloaddefaultupcasetable : return error exfatkillsb() delayedfree() exfatfreeupcasetable() <--------- double free This patch set ->volutil as NULL after freeing it.

1 / 4
Source: Red Hat
First published (updated )
Severity
6.8
EPSS
0.02%
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

net: openvswitch: fix nested key length validation in the set() action

It's not safe to access nlalen(ovskey) if the data is smaller than the netlink header. Check that the attribute is OK first.

1 / 2
Source: Red Hat
First published (updated )
Severity
8.4
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

1 / 3
Source: Microsoft
First published (updated )
Severity
7.8
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

net: afcan: do not leave a dangling sk pointer in cancreate()

On error cancreate() frees the allocated sk object, but sockinitdata() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.

1 / 6
Source: NVD
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203