Where
AND
-Infinity
0
Severity
3.3
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

drm/bridge: cdns-dsi: Replace deprecated UNIVERSALDEVPMOPS()

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

drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers

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

drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

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

btrfs: free mapping node on duplicate reloc root insert

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

btrfs: fix root leak if its reloc root is unexpected in mergerelocroots()

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

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

wifi: brcmfmac: initialize SDIO data work before cleanup

brcmfsdioprobe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmfsdioremove().

brcmfsdioremove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmfsdioremove(), so the cleanup path always observes a valid work object.

This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run.

A QEMU PoC forced allocorderedworkqueue() to fail at the same point in brcmfsdioprobe(), before INITWORK(&bus->datawork) is reached. The resulting fail path calls brcmfsdioremove(), and DEBUGOBJECTS reports the invalid work drain with brcmfsdioprobe() and brcmfsdioremove() in the stack.

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

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

wifi: ipw2100: fix potential memory leak in ipw2100pciinitone()

The memory allocated in the ipw2100allocdevice() function is not freed in some of the error paths in ipw2100pciinitone(). Fix that by converting the direct return into a goto to the error path return.

The error path when pcienabledevice() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.

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

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

wifi: ath9k: hifusb: don't dereference hifdev after re-arming firmware request

ath9khifrequestfirmware() re-arms an asynchronous firmware load via requestfirmwarenowait(), passing hifdev as the completion context, and then still dereferences hifdev:

devinfo(&hifdev->udev->dev, "ath9khtc: Firmware %s requested\n", hifdev->fwname);

The re-armed callback ath9khifusbfirmwarecb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9khifusbfirmwarefail() -> completeall(&hifdev->fwdone). That releases the waitforcompletion(&hifdev->fwdone) in a concurrent ath9khifusbdisconnect(), which then kfree()s hifdev. The trailing devinfo() in the frame that re-armed the request can therefore read freed memory (hifdev->udev, the first field of struct hifdeviceusb):

BUG: KASAN: slab-use-after-free in ath9khifrequestfirmware Read of size 8 ... by task kworker/... ath9khifrequestfirmware ath9khifusbfirmwarecb drivers/net/wireless/ath/ath9k/hifusb.c:1247 requestfirmwareworkfunc Allocated by ...: ath9khifusbprobe drivers/net/wireless/ath/ath9k/hifusb.c Freed by ...: ath9khifusbdisconnect -> kfree drivers/net/wireless/ath/ath9k/hifusb.c

The fwdone barrier only makes disconnect wait for the firmware chain to terminate; it does not protect the outer ath9khifrequestfirmware() frame that re-armed the request and keeps touching hifdev afterwards.

Drop the post-request devinfo(): it is the only use of hifdev after the async request is armed, and it is purely informational (the deverr() on the failure path runs only when requestfirmwarenowait() did not arm a callback, so hifdev is still alive there).

This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9khtc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.

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

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

wifi: ath11k: fix potential buffer underflow in ath11khalrxmsdulistget()

When the first entry in msdudetails has a zero buffer address, the code accesses msdudetails[i - 1] with i == 0, causing a buffer underflow.

Fix similarly to ath12kwifi7halrxmsdulistget() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access.

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

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

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

net: hsr: fix memory leak on slave unregistration by removing synced VLANs

When an HSR master device is brought UP, it auto-adds VLAN 0 via vlanvid0add(), which propagates VID 0 to its slave devices (slave A and B).

If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsrdelport() is called to detach the slave port from the HSR master. However, hsrdelport() currently does not delete the VLAN IDs that were synced to the slave device by HSR.

As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlaninfo / vlanvidinfo structure remains allocated, leading to a memory leak.

Fix this by calling vlanvidsdelbydev(port->dev, master->dev) in hsrdelport() before unlinking slave A or slave B ports, matching the propagation logic in hsrndovlanrxaddvid() / hsrndovlanrxkillvid() and the cleanup behavior in bonding and team drivers.

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

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

wifi: brcmfmac: fix 802.1X-SHA256 call trace warning

Based on wpaauth as 1x256 mode, need to set up "usefwsup" with BRCMFPROFILEFWSUP1X. Or it will happen trace warning when call brcmfcfg80211setpmk().

[ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmfcfg80211setpmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]  <TASK> [ 4481.831205]  nl80211setpmk+0x183/0x250 [cfg80211] [ 4481.831233]  genlfamilyrcvmsgdoit+0xea/0x150 [ 4481.831237]  genlrcvmsg+0x104/0x240 [ 4481.831239]  ? cfg80211probestatus+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genlfamilyrcvmsgdoit+0x150/0x150 [ 4481.831259]  netlinkrcvskb+0x4e/0x100 [ 4481.831261]  genlrcv+0x24/0x40 [ 4481.831262]  netlinkunicast+0x236/0x380 [ 4481.831264]  netlinksendmsg+0x250/0x4b0 [ 4481.831266]  socksendmsg+0x5c/0x70 [ 4481.831269]  syssendmsg+0x236/0x2b0 [ 4481.831271]  ? copymsghdrfromuser+0x6d/0xa0 [ 4481.831272]  syssendmsg+0x86/0xd0 [ 4481.831274]  ? avchasperm+0x8c/0x1a0 [ 4481.831276]  ? preemptcountadd+0x6a/0xa0 [ 4481.831279]  ? sockhasperm+0x82/0xa0 [ 4481.831280]  syssendmsg+0x57/0xa0 [ 4481.831282]  dosyscall64+0x38/0x90 [ 4481.831284]  entrySYSCALL64afterhwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4

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

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

wifi: mt76: connac: fix possible NULL-pointer deref in mt76connacmcuunibsshetlv()

mt76connacgethephycap routine can theoretically return NULL so check cap pointer before dereferencing it.

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

drm/i915/gem: Add missing nospec on parallel submit slot

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

drm/i915/gem: Do not leak siblings[] on proto context error

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

drm/i915: Return NULL on error in activeinstance

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

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

media: cx23885: add ioremap return check and cleanup

Add a check for the return value of pciioremapbar() in cx23885devsetup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV.

This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.

1 / 2
Source: MITRE
First published (updated )
Severity
1.8
AV:P/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L

drm/dpmst: Handle torn-down topology gracefully in drmdpmsttopologyqueueprobe()

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

drm/amd/display: detectlinkandlocalsink: DP alt mode timeout path leaks prevsink reference

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

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

media: nxp: imx8-isi: Add missing v4l2subdevcleanup() in crossbar and pipe

Both mxcisicrossbarinit() and mxcisipipeinit() call v4l2subdevinitfinalize() which allocates the subdev active state, but neither mxcisicrossbarcleanup() nor mxcisipipecleanup() calls v4l2subdevcleanup() to free it.

This causes a memory leak on every rmmod, reported by kmemleak:

unreferenced object 0xffff0000d06fc800 (size 192): comm "(udev-worker)", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleakalloc+0x34/0x40 kvmallocnodenoprof+0x5f8/0x7d8 v4l2subdevstatealloc+0x1fc/0x30c v4l2subdevinitfinalize+0x178/0x368

Add the missing v4l2subdevcleanup() calls before mediaentitycleanup() in both crossbar and pipe cleanup paths.

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

arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates

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