In the Linux kernel, the following vulnerability has been resolved:
rpmsg: char: Fix use-after-free on probe error path
rpmsgchrdevprobe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsgchrdeveptdevadd(). If rpmsgchrdeveptdevadd() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer.
Avoid publishing eptdev through the default endpoint until rpmsgchrdeveptdevadd() succeeds. Messages received before the priv pointer is published should be ignored by rpmsgeptcb(). Flow-control updates can hit rpmsgeptflowcb() in the same window, so make both callbacks return success when priv is NULL.
In the Linux kernel, the following vulnerability has been resolved:
media: amphion: Fix race between m2m jobabort and devicerun
Fix kernel panic caused by race condition where v4l2m2mctxrelease() frees m2mctx while v4l2m2mtryrun() is about to call devicerun with the same context.
Race sequence: v4l2m2mtryrun(): v4l2m2mctxrelease(): lock/unlock v4l2m2mcanceljob() jobabort() v4l2m2mjobfinish() kfree(m2mctx) <- frees ctx devicerun() <- use-after-free crash at 0x538
Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2m2mtryrun+0x78/0x138 v4l2m2mdevicerunwork+0x14/0x20
The amphion vpu driver does not rely on the m2m framework's devicerun callback to perform encode/decode operations.
Fix the race by preventing m2m framework job scheduling entirely: - Add jobready callback returning 0 (no jobs ready for m2m framework) - Remove jobabort callback to avoid the race condition
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: Fix ndtbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. If bonding ARP/NS validation is enabled, an IPv6 NS/NA packet received on a slave can reach bondvalidatena(), which calls bondhasthisip6(). That path calls ipv6chkaddr() and can crash in ipv6chkaddrandflags().
BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ipv6chkaddrandflags+0x69/0x170 Call Trace: <IRQ> ipv6chkaddr+0x1f/0x30 bondvalidatena+0x12e/0x1d0 [bonding] ? pfxbondhandleframe+0x10/0x10 [bonding] bondrcvvalidate+0x1a0/0x450 [bonding] bondhandleframe+0x5e/0x290 [bonding] ? srsoaliasreturnthunk+0x5/0xfbef5 netifreceiveskbcore.constprop.0+0x3e8/0xe50 ? srsoaliasreturnthunk+0x5/0xfbef5 ? updatecfsrqloadavg+0x1a/0x240 ? srsoaliasreturnthunk+0x5/0xfbef5 ? enqueueentity+0x5e/0x240 netifreceiveskbonecore+0x39/0xa0 processbacklog+0x9c/0x150 napipoll+0x30/0x200 ? srsoaliasreturnthunk+0x5/0xfbef5 netrxaction+0x338/0x3b0 handlesoftirqs+0xc9/0x2a0 dosoftirq+0x42/0x60 </IRQ> <TASK> localbhenableip+0x62/0x70 devqueuexmit+0x2d3/0x1000 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? packetparseheaders+0x10a/0x1a0 packetsendmsg+0x10da/0x1700 ? kickpool+0x5f/0x140 ? srsoaliasreturnthunk+0x5/0xfbef5 ? queuework+0x12d/0x4f0 syssendto+0x1f3/0x220 x64syssendto+0x24/0x30 dosyscall64+0x101/0xf80 ? excpagefault+0x6e/0x170 ? srsoaliasreturnthunk+0x5/0xfbef5 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Fix this by checking ipv6modenabled() before dispatching IPv6 packets to bondnarcv(). If IPv6 is disabled, return early from bondrcvvalidate() and avoid the path to ipv6chkaddr().
In the Linux kernel, the following vulnerability has been resolved:
mm/pagealloc: clear page->private in freepagesprepare()
Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via splitpage(), tail pages retain stale page->private values.
This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swapcountcontinued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LISTPOISON values, causing a crash:
KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:dosysswapoff+0x1151/0x1860
Fix this by clearing page->private in freepagesprepare(), ensuring all freed pages have clean state regardless of previous use.
In the Linux kernel, the following vulnerability has been resolved:
media: qcom: camss: vfe: Fix out-of-bounds access in vfeisrregupdate()
vfeisr() iterates using MSMVFEIMAGEMASTERSNUM(7) as the loop bound and passes the index to vfeisrregupdate(). However, vfe->line[] array is defined with VFELINENUMMAX(4):
struct vfeline line[VFELINENUMMAX];
When index is 4, 5, 6, the access to vfe->line[lineid] exceeds the array bounds and resulting in out-of-bounds memory access.
Fix this by using separate loops for output lines and write masters.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: move async event work off nvmet-wq
For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-
A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)
nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)
B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()
C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd
Lockdep splat:
============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90
but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660
3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530
Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390
Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Do not skip unrelated mode changes in DSC validation
Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state modechanged flag to false when recomputing the DSC configuration results in no timing change for a particular stream.
However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the modechanged flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in prevalidatedsc().
At this point, however, dmupdatecrtcstate() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpudmcommitstreams() will never release the old stream, resulting in a memory leak. amdgpudmatomiccommittail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on:
BUG: KASAN: use-after-free in dcstreamrelease+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977
Workqueue: events drmmodermfbworkfn Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 printaddressdescription.constprop.0+0x88/0x320 ? dcstreamrelease+0x25/0x90 [amdgpu] printreport+0xfc/0x1ff ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x225/0x4e0 ? dcstreamrelease+0x25/0x90 [amdgpu] kasanreport+0xe1/0x180 ? dcstreamrelease+0x25/0x90 [amdgpu] kasancheckrange+0x125/0x200 dcstreamrelease+0x25/0x90 [amdgpu] dcstatedestruct+0x14d/0x5c0 [amdgpu] dcstaterelease.part.0+0x4e/0x130 [amdgpu] dmatomicdestroystate+0x3f/0x70 [amdgpu] drmatomicstatedefaultclear+0x8ee/0xf30 ? drmmodeobjectput.part.0+0xb1/0x130 drmatomicstatefree+0x15c/0x2d0 atomicremovefb+0x67e/0x980
Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the modechanged flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the modechanged flag to this earlier value instead in prevalidatedsc().
(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
ext4: fix use-after-free in updatesuperwork when racing with umount
In the Linux kernel, the following vulnerability has been resolved:
net/rds: Fix circular locking dependency in rdstcptune
syzbot reported a circular locking dependency in rdstcptune() where sknetrefcntupgrade() is called while holding the socket lock:
====================================================== WARNING: possible circular locking dependency detected ====================================================== kworker/u10:8/15040 is trying to acquire lock: ffffffff8e9aaf80 (fsreclaim){+.+.}-{0:0}, at: kmalloccachenoprof+0x4b/0x6f0
but task is already holding lock: ffff88805a3c1ce0 (k-sklock-AFINET6){+.+.}-{0:0}, at: rdstcptune+0xd7/0x930
The issue occurs because sknetrefcntupgrade() performs memory allocation (via getnettrack() -> reftrackeralloc()) while the socket lock is held, creating a circular dependency with fsreclaim.
Fix this by moving sknetrefcntupgrade() outside the socket lock critical section. This is safe because the fields modified by the sknetrefcntupgrade() call (sknetrefcnt, nstracker) are not accessed by any concurrent code path at this point.
v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpfxdpfragsincreasetail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDPADJUSTTAILGROWMULTIBUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->fragsize was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINTMAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces.
[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookupswapcgroupid+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaffrompte+0x77/0xa0 [ 7340.422855] swapptebatch+0xa7/0x290 [ 7340.423363] zapnonpresentptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zappterange+0x281/0x580 [ 7340.424607] zappmdrange.isra.0+0xc9/0x240 [ 7340.425177] unmappagerange+0x24d/0x420 [ 7340.425714] unmapvmas+0xa1/0x180 [ 7340.426185] exitmmap+0xe1/0x3b0 [ 7340.426644] mmput+0x41/0x150 [ 7340.427098] exitmm+0xb1/0x110 [ 7340.427539] doexit+0x1b2/0x460 [ 7340.427992] dogroupexit+0x2d/0xc0 [ 7340.428477] getsignal+0x79d/0x7e0 [ 7340.428957] archdosignalorrestart+0x34/0x100 [ 7340.429571] exittousermodeloop+0x8e/0x4c0 [ 7340.430159] dosyscall64+0x188/ ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix use-after-free in pm8001queuecommand()
Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001taskexec()") refactors pm8001queuecommand(), however it introduces a potential cause of a double free scenario when it changes the function to return -ENODEV in case of phy down/device gone state.
In this path, pm8001queuecommand() updates task status and calls taskdone to indicate to upper layer that the task has been handled. However, this also frees the underlying SAS task. A -ENODEV is then returned to the caller. When libsas sasataqcissue() receives this error value, it assumes the task wasn't handled/queued by LLDD and proceeds to clean up and free the task again, resulting in a double free.
Since pm8001queuecommand() handles the SAS task in this case, it should return 0 to the caller indicating that the task has been handled.
In the Linux kernel, the following vulnerability has been resolved:
fprobe: Release rethook after the ftraceops is unregistered
While running bpf selftests it's possible to get following fault:
general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC NOPTI ... Call Trace: <TASK> fprobehandler+0xc1/0x270 ? pfxbpftestmodinit+0x10/0x10 ? pfxbpftestmodinit+0x10/0x10 ? bpffentrytest1+0x5/0x10 ? bpffentrytest1+0x5/0x10 ? bpftestmodinit+0x22/0x80 ? dooneinitcall+0x63/0x2e0 ? rcuiswatching+0xd/0x40 ? kmalloctrace+0xaf/0xc0 ? doinitmodule+0x60/0x250 ? dosysfinitmodule+0xac/0x120 ? dosyscall64+0x37/0x90 ? entrySYSCALL64afterhwframe+0x72/0xdc </TASK>
In unregisterfprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu.
Moving rethookfree call after fp->ops is unregistered with unregisterftracefunction call.
In the Linux kernel, the following vulnerability has been resolved:
tracing/synthetic: Fix races on freeing lastcmd
Currently, the "lastcmd" variable can be accessed by multiple processes asynchronously when multiple users manipulate syntheticevents node at the same time, it could lead to use-after-free or double-free.
This patch add "lastcmdmutex" to prevent "lastcmd" from being accessed asynchronously.
================================================================
It's easy to reproduce in the KASAN environment by running the two scripts below in different shells.
script 1: while : do echo -n -e '\x88' > /sys/kernel/tracing/syntheticevents done
script 2: while : do echo -n -e '\xb0' > /sys/kernel/tracing/syntheticevents done
================================================================ double-free scenario:
process A process B ------------------- --------------- 1.kstrdup lastcmd 2.free lastcmd 3.free lastcmd(double-free)
================================================================ use-after-free scenario:
process A process B ------------------- --------------- 1.kstrdup lastcmd 2.free lastcmd 3.tracinglogerr(use-after-free)
================================================================
Appendix 1. KASAN report double-free:
BUG: KASAN: double-free in kfree+0xdc/0x1d4 Free of addr by task sh/4879 Call trace: ... kfree+0xdc/0x1d4 createordeletesynthevent+0x60/0x1e8 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
Allocated by task 4879: ... kstrdup+0x5c/0x98 createordeletesynthevent+0x6c/0x1e8 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
Freed by task 5464: ... kfree+0xdc/0x1d4 createordeletesynthevent+0x60/0x1e8 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
================================================================ Appendix 2. KASAN report use-after-free:
BUG: KASAN: use-after-free in strlen+0x5c/0x7c Read of size 1 at addr by task sh/5483 sh: CPU: 7 PID: 5483 Comm: sh ... asanreportload1noabort+0x34/0x44 strlen+0x5c/0x7c tracinglogerr+0x60/0x444 createordeletesynthevent+0xc4/0x204 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
Allocated by task 5483: ... kstrdup+0x5c/0x98 createordeletesynthevent+0x80/0x204 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
Freed by task 5480: ... kfree+0xdc/0x1d4 createordeletesynthevent+0x74/0x204 traceparseruncommand+0x2bc/0x4b8 syntheventswrite+0x20/0x30 vfswrite+0x200/0x830 ...
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: char: Avoid double destroy of default endpoint
The rpmsgdevremove() in rpmsgcore is the place for releasing this default endpoint.
So need to avoid destroying the default endpoint in rpmsgchrdeveptdevdestroy(), this should be the same as rpmsgeptdevrelease(). Otherwise there will be double destroy issue that ept->refcount report warning:
refcountt: underflow; use-after-free.
Call trace: refcountwarnsaturate+0xf8/0x150 virtiorpmsgdestroyept+0xd4/0xec rpmsgdevremove+0x60/0x70
The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs: fix use-after-free in stateshow()
stateshow() reads kdamond->damonctx without holding damonsysfslock. This allows a use-after-free race:
CPU 0 CPU 1 ----- ----- stateshow() damonsysfsturndamonon() ctx = kdamond->damonctx; mutexlock(&damonsysfslock); damondestroyctx(kdamond->damonctx); kdamond->damonctx = NULL; mutexunlock(&damonsysfslock); damonisrunning(ctx); / ctx is freed / mutexlock(&ctx->kdamondlock); / UAF /
(The race can also occur with damonsysfskdamondsrmdirs() and damonsysfskdamondrelease(), which free or replace the context under damonsysfslock.)
Fix by taking damonsysfslock before dereferencing the context, mirroring the locking used in pidshow().
The bug has existed since stateshow() first accessed kdamond->damonctx.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Collect command failures data only for known commands
DEVX can issue a general command, which is not used by mlx5 driver. In case such command is failed, mlx5 is trying to collect the failure data, However, mlx5 doesn't create a storage for this command, since mlx5 doesn't use it. This lead to array-index-out-of-bounds error.
Fix it by checking whether the command is known before collecting the failure data.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix kernel crash due to null io->bio
We should return when io->bio is null before doing anything. Otherwise, panic.
BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:submitmergedwritecond+0x164/0x240 [f2fs] Call Trace: <TASK> f2fssubmitmergedwrite+0x1d/0x30 [f2fs] commitcheckpoint+0x110/0x1e0 [f2fs] f2fswritecheckpoint+0x9f7/0xf00 [f2fs] ? pfxissuecheckpointthread+0x10/0x10 [f2fs] checkpointandcompletereqs+0x84/0x190 [f2fs] ? preemptcountadd+0x82/0xc0 ? pfxissuecheckpointthread+0x10/0x10 [f2fs] issuecheckpointthread+0x4c/0xf0 [f2fs] ? pfxautoremovewakefunction+0x10/0x10 kthread+0xff/0x130 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Fix potential RX buffer overflow
If an event caused firmware to return invalid RX size for LARGECONFIGGET, memcpyfromio() could end up copying too many bytes. Fix by utilizing mint().
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: fix UAF issue in ip6mrskdone() when addrconfinitnet() failed
If the initialization fails in calling addrconfinitnet(), devconfall is the pointer that has been released. Then ip6mrskdone() is called to release the net, accessing devconf->mcforwarding directly causes invalid pointer access.
The process is as follows: setupnet() opsinit() addrconfinitnet() all = kmemdup(...) ---> alloc "all" ... net->ipv6.devconfall = all; addrconfsysctlregister() ---> failed ... kfree(all); ---> ipv6.devconfall invalid ... opsexitlist() ... ip6mrskdone() devconf = net->ipv6.devconfall; //devconf is invalid pointer if (!devconf || !atomicread(&devconf->mcforwarding))
The following is the Call Trace information: BUG: KASAN: use-after-free in ip6mrskdone+0x112/0x3a0 Read of size 4 at addr ffff888075508e88 by task ip/14554 Call Trace: <TASK> dumpstacklvl+0x8e/0xd1 printreport+0x155/0x454 kasanreport+0xba/0x1f0 kasancheckrange+0x35/0x1b0 ip6mrskdone+0x112/0x3a0 rawv6close+0x48/0x70 inetrelease+0x109/0x230 inet6release+0x4c/0x70 sockrelease+0x87/0x1b0 igmp6netexit+0x6b/0x170 opsexitlist+0xb0/0x170 setupnet+0x7ac/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f7963322547
</TASK> Allocated by task 14554: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasankmalloc+0xa1/0xb0 kmallocnodetrackcaller+0x4a/0xb0 kmemdup+0x28/0x60 addrconfinitnet+0x1be/0x840 opsinit+0xa5/0x410 setupnet+0x5aa/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0
Freed by task 14554: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 kasanslabfree+0x155/0x1b0 slabfreefreelisthook+0x11b/0x220 kmemcachefree+0xa4/0x360 addrconfinitnet+0x623/0x840 opsinit+0xa5/0x410 setupnet+0x5aa/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0
In the Linux kernel, the following vulnerability has been resolved:
hisiaccvfiopci: bugfix live migration function without VF device driver
If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.
Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: fix potential out-of-bounds write in lan743xptpioeventclockget()
Before calling lan743xptpioeventclockget(), the 'channel' value is checked against the maximum value of PCI11X1XPTPIOMAXCHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTPINTSTS) specifications.
However, lan743xptpioeventclockget() writes to ptp->extts[] with only LAN743XPTPNEXTTS(4) elements, using channel as an index:
lan743xptpioeventclockget(..., u8 channel,...) { ... / Update Local timestamp / extts = &ptp->extts[channel]; extts->ts.tvsec = sec; ... }
To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743XPTPNEXTTS to 8.
Detected using the static analysis tool - Svace.
In the Linux kernel, the following vulnerability has been resolved:
drm/fb-helper: Fix out-of-bounds access
Clip memory range to screen-buffer size to avoid out-of-bounds access in fbdev deferred I/O's damage handling.
Fbdev's deferred I/O can only track pages. From the range of pages, the damage handler computes the clipping rectangle for the display update. If the fbdev screen buffer ends near the beginning of a page, that page could contain more scanlines. The damage handler would then track these non-existing scanlines as dirty and provoke an out-of-bounds access during the screen update. Hence, clip the maximum memory range to the size of the screen buffer.
While at it, rename the variables min/max to minoff/maxoff in drmfbhelperdeferredio(). This avoids confusion with the macros of the same name.
In the Linux kernel, the following vulnerability has been resolved:
bpf, x86: fix freeing of not-finalized bpfprogpack
syzbot reported a few issues with bpfprogpack [1], [2]. This only happens with multiple subprogs. In jitsubprogs(), we first call bpfintjitcompile() on each sub program. And then, we call it on each sub program again. jitdata is not freed in the first call of bpfintjitcompile(). Similarly we don't call bpfjitbinarypackfinalize() in the first call of bpfintjitcompile().
If bpfintjitcompile() failed for one sub program, we will call bpfjitbinarypackfinalize() for this sub program. However, we don't have a chance to call it for other sub programs. Then we will hit "goto outfree" in jitsubprogs(), and call bpfjitfree on some subprograms that haven't got bpfjitbinarypackfinalize() yet.
At this point, bpfjitbinarypackfree() is called and the whole 2MB page is freed erroneously.
Fix this with a custom bpfjitfree() for x8664, which calls bpfjitbinarypackfinalize() if necessary. Also, with custom bpfjitfree(), bpfprogaux->usebpfprogpack is not needed any more, remove it.
[1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f [2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc3-topology: Prevent double freeing of ipccontroldata via loadbytes
We have sanity checks for byte controls and if any of the fail the locally allocated scontrol->ipccontroldata is freed up, but not set to NULL.
On a rollback path of the error the higher level code will also try to free the scontrol->ipccontroldata which will eventually going to lead to memory corruption as double freeing memory is not a good thing.
ASoC: qcom: Fix sc7280 lpass potential buffer overflow
In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: Fix unlocked deletion of default FDB entry
When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
Reproducer:
# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0
Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.
[1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlancore.c:417 vxlanfindmac+0x17f/0x1a0 [...] RIP: 0010:vxlanfindmac+0x17f/0x1a0 [...] Call Trace: <TASK> vxlanfdbdelete+0xbe/0x560 vxlanvnideletegroup+0x2ba/0x940 vxlanvnidel.isra.0+0x15f/0x580 vxlanprocessvnifilter+0x38b/0x7b0 vxlanvnifilterprocess+0x3bb/0x510 rtnetlinkrcvmsg+0x2f7/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 syssendmsg+0xfc/0x180 syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53
In the Linux kernel, the following vulnerability has been resolved:
irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs
On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIONOWAKEIRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs:
root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpmsettype+0x80/0xcc lr : mpmsettype+0x5c/0xcc Call trace: mpmsettype+0x80/0xcc (P) qcommpmsettype+0x64/0x158 irqchipsettypeparent+0x20/0x38 msmgpioirqsettype+0x50/0x530 irqsettrigger+0x60/0x184 setupirq+0x304/0x6bc requestthreadedirq+0xc8/0x19c edgedetectorsetup+0x260/0x364 linereqcreate+0x420/0x5a8 gpioioctl+0x2d4/0x6c0
Fix this by copying the check for GPIONOWAKEIRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs.
drm/amdkfd: Fix mode1 reset crash issue
In the Linux kernel, the following vulnerability has been resolved:
veth: Fix use after free in XDPREDIRECT
Commit 718a18a0c8a6 ("veth: Rework vethxdprcvskb in order to accept non-linear skb") introduced a bug where it tried to use pskbexpandhead() if the headroom was less than XDPPACKETHEADROOM. This however uses kmalloc to expand the head, which will later allow consumeskb() to free the skb while is it still in use by AFXDP.
Previously if the headroom was less than XDPPACKETHEADROOM we continued on to allocate a new skb from pages so this restores that behavior.
BUG: KASAN: use-after-free in xskrcv+0x18d/0x2c0 Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640
CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G O 6.1.4-cloudflare-kasan-2023.1.2 #1 Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S3B10.03 06/21/2018 Call Trace: <TASK> dumpstacklvl+0x34/0x48 printreport+0x170/0x473 ? xskrcv+0x18d/0x2c0 kasanreport+0xad/0x130 ? xskrcv+0x18d/0x2c0 kasancheckrange+0x149/0x1a0 memcpy+0x20/0x60 xskrcv+0x18d/0x2c0 xskmapredirect+0x1f3/0x490 ? vethxdprcvskb+0x89c/0x1ba0 [veth] xdpdoredirect+0x5ca/0xd60 vethxdprcvskb+0x935/0x1ba0 [veth] ? netifreceiveskblistcore+0x671/0x920 ? vethxdp+0x670/0x670 [veth] vethxdprcv+0x304/0xa20 [veth] ? doxdpgeneric+0x150/0x150 ? vethxdprcvone+0xde0/0xde0 [veth] ? rawspinlockbh+0xe0/0xe0 ? newidlebalance+0x887/0xe30 ? perfeventtaskschedin+0xdb/0x800 vethpoll+0x139/0x571 [veth] ? vethxdprcv+0xa20/0xa20 [veth] ? rawspinunlock+0x39/0x70 ? finishtaskswitch.isra.0+0x17e/0x7d0 ? switchto+0x5cf/0x1070 ? schedule+0x95b/0x2640 ? ioscheduletimeout+0x160/0x160 napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 ? napipoll+0x440/0x440 ? kthreadparkme+0xc6/0x1f0 ? napipoll+0x440/0x440 kthread+0x2a2/0x340 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK>
Freed by task 148640: kasansavestack+0x23/0x50 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 kasanslabfree+0x169/0x1d0 slabfreefreelisthook+0xd2/0x190 kmemcachefree+0x1a1/0x2f0 skbreleasedata+0x449/0x600 consumeskb+0x9f/0x1c0 vethxdprcvskb+0x89c/0x1ba0 [veth] vethxdprcv+0x304/0xa20 [veth] vethpoll+0x139/0x571 [veth] napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 kthread+0x2a2/0x340 retfromfork+0x22/0x30
The buggy address belongs to the object at ffff888976250000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 340 bytes inside of 2048-byte region [ffff888976250000, ffff888976250800)
The buggy address belongs to the physical page: page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250 head:00000000ae18262a order:3 compoundmapcount:0 compoundpincount:0 flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff) raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00 raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb <span class="quote">> ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb</span> ^ ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb