In the Linux kernel, the following vulnerability has been resolved:
powerpc/time: Remove redundant preemptdisable|enable() calls from archirqworkraise()
A kernel panic is observed when handling machine check exceptions from real mode.
BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] archirqworkraise+0x10/0x70 LR [c00000000003ffc8] machinecheckqueueevent+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machinecheckqueueevent+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machinecheckearlycommon+0x1f0/0x2c0
The crash occurs because archirqworkraise() calls preemptdisable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preemptcount can fault, leading to the panic.
The preemptdisable()/preemptenable() pair in archirqworkraise() was originally added by commit 0fe1ac48bef0 ("powerpc/perfevent: Fix oops due to perfeventdopending call") to avoid races while raising irq work from exception context.
Later, commit 471ba0e686cb ("irqwork: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irqworkqueue() path, while commit 20b876918c06 ("irqwork: Use per cpu atomics instead of regular atomics") added equivalent protection in irqworkqueueon() before reaching archirqworkraise():
irqworkqueue() / irqworkqueueon() -> preemptdisable() -> irqworkqueuelocal() -> irqworkraise() -> archirqworkraise()
As a result, callers other than mceirqworkraise() already execute with preemption disabled, making the additional preemptdisable()/preemptenable() pair in archirqworkraise() redundant.
The archirqworkraise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preemptdisable()/preemptenable() calls from here.
Remove it to avoid accessing preemptcount from real mode context.
[Maddy: Fixed the commit title]
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix sleep-inside-lock in smcsetsockopt() causing local DoS
A logic flaw in smcsetsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely.
The function smcsetsockopt() calls copyfromsockptr() while holding locksock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held.
Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog.
[ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smcshutdown+... [ 240.123512] locksocknested+...
This patch moves the user-space copy outside the locksock() critical section to prevent the issue.
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix hugetlblock AA deadlock in gethugepageforhwpoison
Two concurrent madvise(MADVHWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlblock when racing with a concurrent unmap:
thread#0 thread#1 -------- -------- madvise(folio, MADVHWPOISON) -> poisons the folio successfully madvise(folio, MADVHWPOISON) unmap(folio) trymemoryfailurehugetlb gethugepageforhwpoison spinlockirq(&hugetlblock) <- held gethugepageforhwpoison hugetlbupdatehwpoison() -> MFHUGETLBFOLIOPREPOISONED goto out: folioput() refcount: 1 -> 0 freehugefolio() spinlockirqsave(&hugetlblock) -> AA DEADLOCK!
The out: path in gethugepageforhwpoison() calls folioput() to drop the GUP reference while the hugetlblock is still held by the hugetlb.c wrapper gethugepageforhwpoison(). If concurrent unmap has released the page table mapping reference, folioput() drops the folio refcount to zero, triggering freehugefolio() which attempts to re-acquire the non-recursive hugetlblock.
Fix this by moving hugetlblock acquisition from the hugetlb.c wrapper into gethugepageforhwpoison(). Place spinunlockirq() before the folioput() at the out: label so the folio is always released outside the lock.
[akpm@linux-foundation.org: fix race, rename label per Miaohe]
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: Fix memory leak after mt76connacmcuallocstareq()
mt76connacmcuallocstareq() allocates an skb which is expected to be freed eventually by mt76mcuskbsendmsg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked.
Specifically, mt76connacmcustawedupdate() and mt76connacmcustakeytlv() may fail, leading to an immediate memory leak in the error path.
Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996mcustakeytlv error") made a similar change.
Compile tested only. Issue found using a prototype static analysis tool and code review.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpfxdpstorebytes proto for read-only arg
While making some maps in Cilium read-only from the BPF side, we noticed that the bpfxdpstorebytes proto is incorrect. In particular, the verifier was throwing the following error:
; ret = ctxstorebytes(ctx, l3off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = (u64 )(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpfxdpstorebytes#190 write into map forbidden, valuesize=6 off=0 size=4
nat comes from a BPFFRDONLYPROG map, so R3 is a PTRTOMAPVALUE. The verifier checks the helper's memory access to R3 in checkmemsizereg, as it reaches ARGCONSTSIZE argument. The third argument has expected type ARGPTRTOUNINITMEM, which includes the MEMWRITE flag. The verifier thus checks for a BPFWRITE access on R3. Given R3 points to a read-only map, the check fails.
Conversely, ARGPTRTOUNINITMEM can also lead to the helper reading from uninitialized memory.
This patch simply fixes the expected argument type to match that of bpfskbstorebytes.
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: initialise event handler read bytes
Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8.
Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff.
In the Linux kernel, the following vulnerability has been resolved:
mctp: i2c: fix skb memory leak in receive path
When 'midev->allowrx' is false, the newly allocated skb isn't consumed by netifrx(), it needs to free the skb directly.
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: CGX: fix bitmap leaks
The RX/TX flow-control bitmaps (rxfcpfvfbmap and txfcpfvfbmap) are allocated by cgxlmacinit() but never freed in cgxlmacexit(). Unbinding and rebinding the driver therefore triggers kmemleak:
unreferenced object (size 16): backtrace: rvuallocbitmap cgxprobe
Free both bitmaps during teardown.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject sleepable kprobemulti programs at attach time
kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpfkprobemultilinkattach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpfcopyfromuser() to be invoked from a non-sleepable context.
This causes a "sleeping function called from invalid context" splat:
BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 1787, name: sudo preemptcount: 1, expected: 0 RCU nest depth: 2, expected: 0
Fix this by rejecting sleepable programs early in bpfkprobemultilinkattach(), before any further processing.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uvc: fix NULL pointer dereference during unbind race
Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown") introduced two stages of synchronization waits totaling 1500ms in uvcfunctionunbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions.
When the PM subsystem starts freezing user space processes, the waiteventinterruptibletimeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL):
[ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind no clean disconnect, wait for release
When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic:
[ 814.292597][ C0] PM: pmsystemirqwakeup: 479 triggered dhdpciehostwake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usbgadgetdeactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usbfunctiondeactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usbgadgetdeactivate+0x14/0xf4 [ 814.404083][ T4558] usbfunctiondeactivate+0x54/0x94 [ 814.404087][ T4558] uvcfunctiondisconnect+0x1c/0x5c [ 814.404092][ T4558] uvcv4l2release+0x44/0xac [ 814.404095][ T4558] v4l2release+0xcc/0x130
Address the race condition and NULL pointer dereference by:
1. State Synchronization (flag + mutex) Introduce a 'funcunbound' flag in struct uvcdevice. This allows uvcfunctiondisconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'funcconnected' for consistent state management.
2. Explicit Synchronization (completion) Use a completion to synchronize uvcfunctionunbind() with the uvcvdevrelease() callback. This prevents Use-After-Free (UAF) by ensuring struct uvcdevice is freed after all video device resources are released.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs: check contexts->nr before accessing contextsarr[0]
Multiple sysfs command paths dereference contextsarr[0] without first verifying that kdamond->contexts->nr == 1. A user can set nrcontexts to 0 via sysfs while DAMON is running, causing NULL pointer dereferences.
In more detail, the issue can be triggered by privileged users like below.
First, start DAMON and make contexts directory empty (kdamond->contexts->nr == 0).
# damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/nrcontexts
Then, each of below commands will cause the NULL pointer dereference.
# echo updateschemesstats > state # echo updateschemestriedregions > state # echo updateschemestriedbytes > state # echo updateschemeseffectivequotas > state # echo updatetunedintervals > state
Guard all commands (except OFF) at the entry point of damonsysfshandlecmd().
In the Linux kernel, the following vulnerability has been resolved:
Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"
This reverts commit 7294863a6f01248d72b61d38478978d638641bee.
This commit was erroneously applied again after commit 0ab5d711ec74 ("drm/amd: Refactor amdgpuaspm to be evaluated per device") removed it, leading to very hard to debug crashes, when used with a system with two AMD GPUs of which only one supports ASPM.
(cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure
When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.
Cleanup the directories under such failures.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs-scheme: cleanup accesspattern subdirs on scheme dir setup failure
When a DAMOS-scheme DAMON sysfs directory setup fails after setup of accesspattern/ directory, subdirectories of accesspattern/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.
Cleanup the directories under such failures.
In the Linux kernel, the following vulnerability has been resolved:
bpf, testrun: Subtract size of xdpframe from allowed metadata size
The xdpframe structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpftestrun, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom).
If userspace supplies such a large metadata size in live packet mode, the xdpupdateframefrombuff() call in xdptestruninitpage() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff.
The commit in the Fixes tag fixed a related bug where the second check in xdpupdateframefrombuff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.
In the Linux kernel, the following vulnerability has been resolved:
pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu
For i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset and clock enable bits, but is ungated and reset together with the VPUs. So we can't reset G1 or G2 separately, it may led to the system hang. Remove rstmask and clkmask of imx8mqvpublkctldomaindata. Let imx8mqvpupowernotifier() do really vpu reset.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reference count leak in bpfprogtestrunxdp()
syzbot is reporting
unregisternetdevice: waiting for sit0 to become free. Usage count = 2
problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().
According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().
Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().
In the Linux kernel, the following vulnerability has been resolved:
parisc: Do not reprogram affinitiy on ASP chip
The ASP chip is a very old variant of the GSP chip and is used e.g. in HP 730 workstations. When trying to reprogram the affinity it will crash with a HPMC as the relevant registers don't seem to be at the usual location. Let's avoid the crash by checking the sversion. Also note, that reprogramming isn't necessary either, as the HP730 is a just a single-CPU machine.
In the Linux kernel, the following vulnerability has been resolved:
media: amphion: fix REVERSEINULL issues reported by coverity
null-checking of a pointor is suggested before dereferencing it
In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bibdev in drbdreqnew) moved a biosetdev call (which has since been removed) to "earlier", from drbdrequestprepare to drbdreqnew.
The problem is that this accesses device->ldev->backingbdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the privatebio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
In the Linux kernel, the following vulnerability has been resolved:
iouring: fix fget leak when fs don't support nowait buffered read
Heming reported a BUG when using iouring doing link-cp on ocfs2. [1]
Do the following steps can reproduce this BUG: mount -t ocfs2 /dev/vdc /mnt/ocfs2 cp testfile /mnt/ocfs2/ ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1 umount /mnt/ocfs2
Then umount will fail, and it outputs: umount: /mnt/ocfs2: target is busy.
While tracing umount, it blames mntgetcount() not return as expected. Do a deep investigation for fget()/fput() on related code flow, I've finally found that fget() leaks since ocfs2 doesn't support nowait buffered read.
ioissuesqe |-ioassignfile // do fget() first |-ioread |-ioiterdoread |-ocfs2filereaditer // return -EOPNOTSUPP |-kiocbdone |-iorwdone |-iocompleterwcommon // set REQFREISSUE |-ioresubmitprep |-ioreqprepasync // override req->file, leak happens
This was introduced by commit a196c78b5443 in v5.18. Fix it by don't re-assign req->file if it has already been assigned.
[1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix potential leak in rtw89appendprobereqie()
Do kfreeskb(new) before goto out to prevent potential leak.
In the Linux kernel, the following vulnerability has been resolved:
power: supply: axp288fuelgauge: Fix externalpowerchanged race
fuelgaugeexternalpowerchanged() dereferences info->bat, which gets sets in axp288fuelgaugeprobe() like this:
info->bat = devmpowersupplyregister(dev, &fuelgaugedesc, &psycfg);
As soon as devmpowersupplyregister() has called deviceadd() the externalpowerchanged callback can get called. So there is a window where fuelgaugeexternalpowerchanged() may get called while info->bat has not been set yet leading to a NULL pointer dereference.
Fixing this is easy. The externalpowerchanged callback gets passed the powersupply which will eventually get stored in info->bat, so fuelgaugeexternalpowerchanged() can simply directly use the passed in psy argument which is always valid.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix unregisternetdev call order in macbremove()
When removing a macb device, the driver calls phyexit() before unregisternetdev(). This leads to a WARN from kernfs:
------------[ cut here ]------------ kernfs: can not remove 'attacheddev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfsremovebynamens+0xd8/0xf0 sysfsremovelink+0x24/0x58 phydetach+0x5c/0x168 phydisconnect+0x4c/0x70 phylinkdisconnectphy+0x6c/0xc0 [phylink] macbclose+0x6c/0x170 [macb] ... macbremove+0x60/0x168 [macb] platformremove+0x5c/0x80 ...
The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus.
Fix this by moving unregisternetdev() ahead of phyexit() in macbremove().
In the Linux kernel, the following vulnerability has been resolved:
clk: imx: clk-imxrt1050: fix memory leak in imxrt1050clocksprobe
Use devmofiomap() instead of ofiomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devmkzalloc() instead will automatically free the memory using devmkfree().
Also, fix error handling of hws by adding unregisterhws label, which unregisters remaining hws when iomap failed.
In the Linux kernel, the following vulnerability has been resolved:
md/raid5-cache: fix null-ptr-deref for r5lflushstripetoraid()
r5lflushstripetoraid() will check if the list 'flushingios' is empty, and then submit 'flushbio', however, r5llogflushendio() is clearing the list first and then clear the bio, which will cause null-ptr-deref:
T1: submit flush io raid5d handleactivestripes r5lflushstripetoraid // list is empty // add 'ioendios' to the list bioinit submitbio // io1
T2: io1 is done r5llogflushendio listsplicetailinit // clear the list T3: submit new flush io ... r5lflushstripetoraid // list is empty // add 'ioendios' to the list bioinit biouninit // clear bio->biblkg submitbio // null-ptr-deref
Fix this problem by clearing bio before clearing the list in r5llogflushendio().
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't allow journal inode to have encrypt flag
Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscryptlimitioblocks() when the 'inlinecrypt' mount option is used.
The problem is that when jbd2journalinitinode() calls bmap(), it eventually finds its way into ext4iomapbegin(), which calls fscryptlimitioblocks(). fscryptlimitioblocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never "opened" like a normal file would be. Hence the crash.
A reproducer is:
mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R "setinodefield <8> flags 0x80808" mount /dev/vdb /mnt -o inlinecrypt
To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.)
I've marked this as fixing the commit that introduced the call to fscryptlimitioblocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature.
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix memory leaks in error path
The memory allocated by vxlanvnigroupinit() is not freed in the error path, leading to memory leaks [1]. Fix by calling vxlanvnigroupuninit() in the error path.
The leaks can be reproduced by annotating grocellsinit() with ALLOWERRORINJECTION() and then running:
# echo "100" > /sys/kernel/debug/failfunction/probability # echo "1" > /sys/kernel/debug/failfunction/times # echo "grocellsinit" > /sys/kernel/debug/failfunction/inject # printf %#x -12 > /sys/kernel/debug/failfunction/grocellsinit/retval # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter RTNETLINK answers: Cannot allocate memory
[1] unreferenced object 0xffff88810db84a00 (size 512): comm "ip", pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v............. 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H........... backtrace: [<ffffffff81a3097a>] kmalloctrace+0x2a/0x60 [<ffffffff82f049fc>] vxlanvnigroupinit+0x4c/0x160 [<ffffffff82ecd69e>] vxlaninit+0x1ae/0x280 [<ffffffff836858ca>] registernetdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] vxlandevcreate+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlannewlink+0xd6/0x130 [<ffffffff836d02ab>] rtnlnewlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnlnewlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlinkrcvmsg+0x43f/0xd40 [<ffffffff83908ce0>] netlinkrcvskb+0x170/0x440 [<ffffffff839066af>] netlinkunicast+0x53f/0x810 [<ffffffff839072d8>] netlinksendmsg+0x958/0xe70 [<ffffffff835c319f>] syssendmsg+0x78f/0xa90 [<ffffffff835cd6da>] syssendmsg+0x13a/0x1e0 [<ffffffff835cd94c>] syssendmsg+0x11c/0x1f0 [<ffffffff8424da78>] dosyscall64+0x38/0x80 unreferenced object 0xffff88810e76d5f8 (size 192): comm "ip", pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O..... 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v..... backtrace: [<ffffffff81a3162e>] kmallocnode+0x4e/0x90 [<ffffffff81a0e166>] kvmallocnode+0xa6/0x1f0 [<ffffffff8276e1a3>] buckettablealloc.isra.0+0x83/0x460 [<ffffffff8276f18b>] rhashtableinit+0x43b/0x7c0 [<ffffffff82f04a1c>] vxlanvnigroupinit+0x6c/0x160 [<ffffffff82ecd69e>] vxlaninit+0x1ae/0x280 [<ffffffff836858ca>] registernetdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] vxlandevcreate+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlannewlink+0xd6/0x130 [<ffffffff836d02ab>] rtnlnewlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnlnewlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlinkrcvmsg+0x43f/0xd40 [<ffffffff83908ce0>] netlinkrcvskb+0x170/0x440 [<ffffffff839066af>] netlinkunicast+0x53f/0x810 [<ffffffff839072d8>] netlinksendmsg+0x958/0xe70 [<ffffffff835c319f>] syssendmsg+0x78f/0xa90
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq25890: Fix externalpowerchanged race
bq25890chargerexternalpowerchanged() dereferences bq->charger, which gets sets in bq25890powersupplyinit() like this:
bq->charger = devmpowersupplyregister(bq->dev, &bq->desc, &psycfg);
As soon as devmpowersupplyregister() has called deviceadd() the externalpowerchanged callback can get called. So there is a window where bq25890chargerexternalpowerchanged() may get called while bq->charger has not been set yet leading to a NULL pointer dereference.
This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f when the chtwcovepwrsrc (extcon) powersupply is done with detecting the connected charger-type which happens to exactly hit the small window:
BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> RIP: 0010:powersupplyissuppliedby+0xb/0xb0 <snip> Call Trace: <TASK> powersupplygetsupplierproperty+0x19/0x50 classforeachdevice+0xb1/0xe0 powersupplygetpropertyfromsupplier+0x2e/0x50 bq25890chargerexternalpowerchanged+0x38/0x1b0 [bq25890charger] powersupplychangedwork+0x30/0x40 classforeachdevice+0xb1/0xe0 powersupplychangedwork+0x5f/0xe0 <snip>
Fixing this is easy. The externalpowerchanged callback gets passed the powersupply which will eventually get stored in bq->charger, so bq25890chargerexternalpowerchanged() can simply directly use the passed in psy argument which is always valid.
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for example qat4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat4xxx.ko) is unloaded, while the core driver (intelqat.ko) remains loaded.
Since the driver uses a shared workqueue (qatmiscwq) across all devices and owned by intelqat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pmbhhandler+0x1d2/0x250 [intelqat] Call Trace: pmbhhandler+0x1d2/0x250 [intelqat] processonework+0x171/0x340 workerthread+0x277/0x3a0 kthread+0xf0/0x120 retfromfork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.
Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.