Where
AND
-Infinity
0
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:

mt76: mt7615: Fix memory leak in mt7615mcuwtblstaadd()

In mt7615mcuwtblstaadd(), an skb sskb is allocated. If the subsequent call to mt76connacmcuallocwtblreq() fails, the function returns an error without freeing sskb, leading to a memory leak.

Fix this by calling devkfreeskb() on sskb in the error handling path to ensure it is properly released.

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

crypto: starfive - Correctly handle return of sgnentsforlen

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

backlight: led-bl: Add devlink to supplier LEDs

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

drm/vgem-fence: Fix potential deadlock on release

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
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:

staging: most: remove broken i2c driver

The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging.

Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

First published (updated )
Severity
5.5
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

bpf: Free special fields when update [lru,]percpuhash maps

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

bpf: Fix invalid prog->stats access when updateeffectiveprogs fails

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

ima: Handle error code returned by imafilterrulematch()

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

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

smack: fix bug: unprivileged task can create labels

If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current

This occurs because dosetattr() imports the provided label in advance, before checking "relabel-self" list.

This change ensures that the "relabel-self" list is checked before importing the label.

1 / 2
Source: NVD
First published (updated )
Severity
5.5
Race Condition
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:

gpu: host1x: Fix race in syncpt alloc/free

Fix race condition between host1xsyncptalloc() and host1xsyncptput() by using krefputmutex() instead of krefput() + manual mutex locking.

This ensures no thread can acquire the syncptmutex after the refcount drops to zero but before syncptrelease acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release.

Remove explicit mutex locking in syncptrelease as krefputmutex() handles this atomically.

First published (updated )
Severity
4.7
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

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

ntfs3: fix uninit memory after failed miread in miformatnew

Fix a KMSAN un-init bug found by syzkaller.

ntfsgetbh() expects a buffer from sbgetblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN.

Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.

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

bpf: Do not let BPF test infra emit invalid GSO types to stack

1 / 2
Source: Microsoft
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:

bpf: Fix stackmap overflow check in bpfgetstackid()

Syzkaller reported a KASAN slab-out-of-bounds write in bpfgetstackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.

First published (updated )
Severity
6.4
Use After Free
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

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

coresight: ETR: Fix ETR buffer use-after-free issue

When ETR is enabled as CSMODESYSFS, if the buffer size is changed and enabled again, currently sysfsbuf will point to the newly allocated memory(bufnew) and free the old memory(bufold). But the etrbuf that is being used by the ETR remains pointed to bufold, not updated to bufnew. In this case, it will result in a memory use-after-free issue.

Fix this by checking ETR's mode before updating and releasing bufold, if the mode is CSMODESYSFS, then skip updating and releasing it.

First published (updated )
Severity
5.5
Use After Free
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:

md: fix rcu protection in mdwakeupthread

We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling mdwakeupthread(). This means that the RCU pointer has been acquired before rcureadlock(), which renders rcureadlock() ineffective and could lead to a use-after-free.

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:

nbd: defer config put in recvwork

There is one uaf issue in recvwork when running NBDCLEARSOCK and NBDCMDRECONFIGURE: nbdgenlconnect // confref=2 (connect and recvwork A) nbdopen // confref=3 recvwork A done // confref=2 NBDCLEARSOCK // confref=1 nbdgenlreconfigure // confref=2 (trigger recvwork B) close nbd // confref=1 recvwork B configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Or only running NBDCLEARSOCK: nbdgenlconnect // confref=2 nbdopen // confref=3 NBDCLEARSOCK // confref=2 close nbd nbdrelease configput // confref=1 recvwork configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Commit 87aac3a80af5 ("nbd: call nbdconfigput() before notifying the waiter") moved nbdconfigput() to run before waking up the waiter in recvwork, in order to ensure that nbdstartdeviceioctl() would not be woken up while nbd->taskrecv was still uncleared.

However, in nbdstartdeviceioctl(), after being woken up it explicitly calls flushworkqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.

Move nbdconfigput() to the end of recvwork, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recvwork is still running, even if clear + reconfigure interleave.

In addition, we don't need to worry about recvwork dropping the last nbdput (which causes deadlock):

path A (netlink with NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=1 (trigger recvwork) open nbd // nbdrefs=2 NBDCLEARSOCK close nbd nbdrelease nbddisconnectandput flushworkqueue // recvwork done nbdconfigput nbdput // nbdrefs=1 nbdput // nbdrefs=0 queuework

path B (netlink without NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=2 (trigger recvwork) open nbd // nbdrefs=3 NBDCLEARSOCK // confrefs=2 close nbd nbdrelease nbdconfigput // confrefs=1 nbdput // nbdrefs=2 recvwork done // confrefs=0, nbdrefs=1 rmmod // nbdrefs=0

Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbdconfigput")

1 / 2
Source: NVD
First published (updated )
Severity
5.5
Use After Free, Race Condition
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:

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

First published (updated )
Severity
5.5
Use After Free
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:

nbd: defer config unlock in nbdgenlconnect

There is one use-after-free warning when running NBDCMDCONNECT and NBDCLEARSOCK:

nbdgenlconnect nbdallocandinitconfig // configrefs=1 nbdstartdevice // configrefs=2 set NBDRTHASCONFIGREF open nbd // configrefs=3 recvwork done // configrefs=2 NBDCLEARSOCK // configrefs=1 close nbd // configrefs=0 refcountinc -> uaf

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcountwarnsaturate+0x12e/0x290 nbdgenlconnect+0x16d0/0x1ab0 genlfamilyrcvmsgdoit+0x1f3/0x310 genlrcvmsg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before refcountinc(&nbd->configrefs) in nbdgenlconnect():

mutexunlock(&nbd->configlock); if (!ret) { setbit(NBDRTHASCONFIGREF, &config->runtimeflags); + printk("before sleep\n"); + mdelay(5 1000); + printk("after sleep\n"); refcountinc(&nbd->configrefs); nbdconnectreply(info, nbd->index); }

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

bpf: Check skb->transportheader is set in bpfskbcheckmtu

1 / 2
Source: Microsoft
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:

ocfs2: relax BUG() to ocfs2error() in ocfs2moveextent()

In 'ocfs2moveextent()', relax 'BUG()' to 'ocfs2error()' just to avoid crashing the whole kernel due to a filesystem corruption.

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:

wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187rxcb()

The rtl8187rxcb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actuallength) is large enough to contain this header.

If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.

Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.

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

btrfs: fix racy bitfield write in btrfsclearspaceinfofull()

1 / 2
Source: Microsoft
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:

gfs2: Prevent recursive memory reclaim

Function newinode() returns a new inode with inode->imapping->gfpmask set to GFPHIGHUSERMOVABLE. This value includes the GFPFS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory.

Worse than that is that it can also deadlock: for example, in several places, gfs2unstuffdinode() is called inside filesystem transactions. This calls filemapgrabfolio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue.

To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfpmask of inode address spaces doesn't include GFPFS.

The "meta" and resource group address spaces were already using GFPNOFS as their gfpmask (which doesn't include GFPFS). The default value of GFPHIGHUSERMOVABLE is less restrictive than GFPNOFS, though. To avoid being overly limiting, use the default value and only knock off the GFPFS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt.

This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").

Fixes xfstest generic/273.

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:

iomap: allocate sdiodonewq for async reads as well

Since commit 222f2c7c6d14 ("iomap: always run error completions in user context"), read error completions are deferred to sdiodonewq. This means the workqueue also needs to be allocated for async reads.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Use After Free
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:

regulator: core: Protect regulatorsupplyaliaslist with regulatorlistmutex

regulatorsupplyaliaslist was accessed without any locking in regulatorsupplyalias(), regulatorregistersupplyalias(), and regulatorunregistersupplyalias(). Concurrent registration, unregistration and lookups can race, leading to:

1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.

Protect all traversals, insertions and deletions on regulatorsupplyaliaslist with the existing regulatorlistmutex.

First published (updated )
Severity
5.5
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:

ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41hdareadacpi()

The acpigetfirstphysicalnode() function can return NULL, in which case the getdevice() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash.

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

First published (updated )
Severity
5.5
Integer Overflow
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

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

ALSA: wavefront: Fix integer overflow in sample size validation

The wavefrontsendsample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem

Fix by using unsigned comparison to avoid integer overflow.

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