In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix potential memleak in paprgetattr()
buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.
ath11k: fix the warning of devwake in mhipmdisabletransition()
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: avoid null dereference in deinit
If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the coredeinit function anymore.
Avoid this null pointer derefence by skipping the call when necessary.
In the Linux kernel, the following vulnerability has been resolved:
arm64: compat: Do not treat syscall number as ESRELx for a bad syscall
If a compat process tries to execute an unknown system call above the ARMNRCOMPATEND number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() -> arm64showsignal().
arm64showsignal() interprets a non-zero value for current->thread.faultcode as an exception syndrome and displays the message associated with the ESRELx.EC field (bits 31:26). current->thread.faultcode is set in compatarmsyscall() -> arm64notifydie() with the bad syscall number instead of a valid ESRELx value. This means that the ESRELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages. For example, for the syscall number 0x68000000, which evaluates to ESRELx.EC value of 0x1A (ESRELxECFPAC) the kernel prints this error:
[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]
which is misleading, as the bad compat syscall has nothing to do with pointer authentication.
Stop arm64showsignal() from printing exception syndrome information by having compatarmsyscall() set the ESRELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes:
[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]
which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace.
A 32-bit value above or equal to 0x80000000 is interpreted as a negative integer in compatarmsyscal() and the condition scno < ARMNRCOMPATEND evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64notifydie() being called.
In the Linux kernel, the following vulnerability has been resolved:
ath11k: disable spectral scan during spectral deinit
When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash.
Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectraldeinit API to avoid this crash.
call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11kspectralprocessdata+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11kspectralprocessdata [ath11k]) from [<7f917fdc>] (ath11kdbringbufferreleaseevent+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11kdbringbufferreleaseevent [ath11k]) from [<7f8ea3c4>] (ath11kwmitlvoprx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11kwmitlvoprx [ath11k]) from [<7f8fe868>] (ath11khtcrxcompletionhandler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11khtcrxcompletionhandler [ath11k]) from [<7f91308c>] (ath11kceperengineservice+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11kceperengineservice [ath11k]) from [<7f9a4198>] (ath11kpcicetasklet+0x28/0x80 [ath11kpci]) [ 1253.514811] [<7f9a4198>] (ath11kpcicetasklet [ath11kpci]) from [<8032227c>] (taskletactioncommon.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (taskletactioncommon.constprop.2) from [<803021e8>] (dosoftirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (dosoftirq) from [<80322610>] (irqexit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irqexit) from [<8036a4a4>] (handledomainirq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (handledomainirq) from [<805eb348>] (gichandleirq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gichandleirq) from [<80301a78>] (irqsvc+0x58/0x8c)
Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPLSILICONZ-1
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid f2fsbugon() in decvalidnodecount()
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215897
I have encountered a bug in F2FS file system in kernel v5.17.
The kernel should enable CONFIGKASAN=y and CONFIGKASANINLINE=y. You can reproduce the bug by running the following commands:
The kernel message is shown below:
kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fsremoveinodepage+0x2a2/0x830 f2fsevictinode+0x9b7/0x1510 evict+0x282/0x4e0 dounlinkat+0x33a/0x540 x64sysunlinkat+0x8e/0xd0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae
The root cause is: .totalvalidblockcount or .totalvalidnodecount could fuzzed to zero, then once decvalidnodecount() was called, it will cause BUGON(), this patch fixes to print warning info and set SBINEEDFSCK into CP instead of panic.
In the Linux kernel, the following vulnerability has been resolved:
soc: ti: tiscipmdomains: Check for null return of devmkcalloc
The allocation funciton devmkcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devmkcalloc in previous code.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on totaldatablocks
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215916
The kernel message is shown below:
kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocatesegmentbydefault+0x228/0x440 f2fsallocatedatablock+0x13d1/0x31f0 dowritepage+0x18d/0x710 f2fsoutplacewritedata+0x151/0x250 f2fsdowritedatapage+0xef9/0x1980 movedatapage+0x6af/0xbc0 dogarbagecollect+0x312f/0x46f0 f2fsgc+0x6b0/0x3bc0 f2fsbalancefs+0x921/0x2260 f2fswritesingledatapage+0x16be/0x2370 f2fswritecachepages+0x428/0xd00 f2fswritedatapages+0x96e/0xd50 dowritepages+0x168/0x550 writebacksingleinode+0x9f/0x870 writebacksbinodes+0x47d/0xb20 writebackinodeswb+0xb2/0x200 wbwriteback+0x4bd/0x660 wbworkfn+0x5f3/0xab0 processonework+0x79f/0x13e0 workerthread+0x89/0xf60 kthread+0x26a/0x300 retfromfork+0x22/0x30 RIP: 0010:newcurseg+0xe8d/0x15f0
The root cause is: ckpt.validblockcount is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment.
So that during garbage colloection, it triggers panic when LFS allocator fails to find free segment.
This patch tries to fix this issue by checking consistency in between ckpt.validblockcount and block accounted from SIT.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to clear dirty inode in f2fsevictinode()
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215904
The kernel message is shown below:
kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 dentrykill+0x2b2/0x4d0 shrinkdentrylist+0x17c/0x4f0 shrinkdcacheparent+0x143/0x1e0 doonetree+0x9/0x30 shrinkdcacheforumount+0x51/0x120 genericshutdownsuper+0x5c/0x3a0 killblocksuper+0x90/0xd0 killf2fssuper+0x225/0x310 deactivatelockedsuper+0x78/0xc0 cleanupmnt+0x2b7/0x480 taskworkrun+0xc8/0x150 exittousermodeprepare+0x14a/0x150 syscallexittousermode+0x1d/0x40 dosyscall64+0x48/0x90
The root cause is: inode node and dnode node share the same nid, so during f2fsevictinode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBINEEDFSCK flag in filesystem.
output from dump.f2fs: [printnodeinfo: 354] Node ID [0xf:15] is inode inid[0] [0x f : 15]
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check for inline inode
Yanming reported a kernel bug in Bugzilla kernel [1], which can be reproduced. The bug message is:
The kernel message is shown below:
kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 dentrykill+0x2b2/0x4d0 dput+0x2dd/0x720 dorenameat2+0x596/0x970 x64sysrename+0x78/0x90 dosyscall64+0x3b/0x90
[1] https://bugzilla.kernel.org/showbug.cgi?id=215895
The bug is due to fuzzed inode has both inlinedata and encrypted flags. During f2fsevictinode(), as the inode was deleted by rename(), it will cause inline data conversion due to conflicting flags. The page cache will be polluted and the panic will be triggered in clearinode().
Try fixing the bug by doing more sanity checks for inline data inode in sanitycheckinode().
In the Linux kernel, the following vulnerability has been resolved:
f2fs: remove WARNON in f2fsisvalidblkaddr
Syzbot triggers two WARNs in f2fsisvalidblkaddr and isbitmapvalid. For example, in f2fsisvalidblkaddr, if type is DATAGENERICENHANCE or DATAGENERICENHANCEREAD, it invokes WARNON if blkaddr is not in the right range. The call trace is as follows:
f2fsgetnodeinfo+0x45f/0x1070 readnodepage+0x577/0x1190 getnodepage.part.0+0x9e/0x10e0 getnodepage f2fsgetnodepage+0x109/0x180 doreadinode f2fsiget+0x2a5/0x58b0 f2fsfillsuper+0x3b39/0x7ca0
Fix these two WARNs by replacing WARNON with dumpstack.
In the Linux kernel, the following vulnerability has been resolved:
vxlan: check vxlanvnigroupinit() return value
vxlaninit() must check vxlanvnigroupinit() success otherwise a crash happens later, spotted by syzbot.
Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlanvnigroupuninit+0x89/0x500 drivers/net/vxlan/vxlanvnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlanuninit+0x1ab/0x200 drivers/net/vxlan/vxlancore.c:2942 unregisternetdevicemanynotify+0x12d6/0x1f30 net/core/dev.c:11824 unregisternetdevicemany net/core/dev.c:11866 [inline] unregisternetdevicequeue+0x307/0x3f0 net/core/dev.c:11736 registernetdevice+0x1829/0x1eb0 net/core/dev.c:10901 vxlandevcreate+0x7c6/0xa30 drivers/net/vxlan/vxlancore.c:3981 vxlannewlink+0xd1/0x130 drivers/net/vxlan/vxlancore.c:4407 rtnlnewlinkcreate net/core/rtnetlink.c:3795 [inline] rtnlnewlink net/core/rtnetlink.c:3906 [inline]
In the Linux kernel, the following vulnerability has been resolved:
ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelinitflow()
There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1].
Fix by using l3mdevmasterupperifindexbyindex() which will acquire the RCU read lock before calling l3mdevmasterupperifindexbyindexrcu().
[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60
stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 devgetbyindexrcu+0x1d3/0x210 l3mdevmasterupperifindexbyindexrcu+0x2b/0xf0 iptunnelbinddev+0x72f/0xa00 iptunnelnewlink+0x368/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8723bs: Fix deadlock in rtwsurveydoneeventcallback()
There is a deadlock in rtwsurveydoneeventcallback(), which is shown below:
(Thread 1) | (Thread 2) | settimer() rtwsurveydoneeventcallback()| modtimer() spinlockbh() //(1) | (wait a time) ... | rtwscantimeouthandler() deltimersync() | spinlockbh() //(2) (wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and use deltimersync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtwsurveydoneeventcallback() will block forever.
This patch extracts deltimersync() from the protection of spinlockbh(), which could let timer handler to obtain the needed lock. Whats more, we change spinlockbh() in rtwscantimeouthandler() to spinlockirq(). Otherwise, spinlockbh() will also cause deadlock() in timer handler.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check if modulo is 0 before dividing.
[How & Why] If a value of 0 is read, then this will cause a divide-by-0 panic.
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:
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 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:
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.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: only set fullmesh for subflow endp
With the in-kernel path-manager, it is possible to change the 'fullmesh' flag. The code in mptcppmnlfullmesh() expects to change it only on 'subflow' endpoints, to recreate more or less subflows using the linked address.
Unfortunately, the setflags() hook was a bit more permissive, and allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not allowed before.
That's what syzbot found, triggering the following warning:
WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 marksubflowendpavailable net/mptcp/pmnetlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcppmnlfullmesh net/mptcp/pmnetlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcpnlsetflags net/mptcp/pmnetlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcppmnlsetflags+0x974/0xdc0 net/mptcp/pmnetlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:marksubflowendpavailable net/mptcp/pmnetlink.c:1496 [inline] RIP: 0010:mptcppmnlfullmesh net/mptcp/pmnetlink.c:1980 [inline] RIP: 0010:mptcpnlsetflags net/mptcp/pmnetlink.c:2003 [inline] RIP: 0010:mptcppmnlsetflags+0x974/0xdc0 net/mptcp/pmnetlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48 RSP: 0018:ffffc9000d307240 EFLAGS: 00010293 RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0 R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2542 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 syssendmsg net/socket.c:2637 [inline] syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5fe8785d29 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:00007fff571f5558 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007 RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index
The Linux kernel CVE team has assigned CVE-2024-26783 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T
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:
list: fix a data-race around ep->rdllist
eppoll() first calls epeventsavailable() with no lock held and checks if ep->rdllist is empty by listemptycareful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INITLISTHEADRCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless epeventsavailable(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epollwait()") made some epeventsavailable() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last epeventsavailable() lockless.
BUG: KCSAN: data-race in doepollwait / doepollwait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INITLISTHEAD include/linux/list.h:38 [inline] listspliceinit include/linux/list.h:492 [inline] epstartscan fs/eventpoll.c:622 [inline] epsendevents fs/eventpoll.c:1656 [inline] eppoll fs/eventpoll.c:1806 [inline] doepollwait+0x4eb/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] dosysepollpwait fs/eventpoll.c:2281 [inline] sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: listemptycareful include/linux/list.h:329 [inline] epeventsavailable fs/eventpoll.c:381 [inline] eppoll fs/eventpoll.c:1797 [inline] doepollwait+0x279/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] dosysepollpwait fs/eventpoll.c:2281 [inline] sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
In the Linux kernel, the following vulnerability has been resolved:
efi: Do not import certificates from UEFI Secure Boot for T2 Macs
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 eficrashgracefullyonpagefault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> pagefaultoops+0x4f/0x2c0 ? searchbpfextables+0x6b/0x80 ? searchmoduleextables+0x50/0x80 ? searchexceptiontables+0x5b/0x60 kernelmodefixuporoops+0x9e/0x110 badareanosemaphore+0x155/0x190 badareanosemaphore+0x16/0x20 dokernaddrfault+0x8c/0xa0 excpagefault+0xd8/0x180 asmexcpagefault+0x1e/0x30 (Removed some logs from here) ? eficall+0x28/0x30 ? switchmm+0x20/0x30 ? eficallrts+0x19a/0x8e0 ? processonework+0x222/0x3f0 ? workerthread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? processonework+0x3f0/0x3f0 ? setkthreadstruct+0x40/0x40 ? retfromfork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efirtswq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000
So we avoid reading these UEFI variables and thus prevent the crash.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icpopalinit()
The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: Fix refcount leak in xivespaprinit
offindcompatiblenode() returns a node pointer with refcount incremented, we should use ofnodeput() on it when done. Add missing ofnodeput() to avoid refcount leak.
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:
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:
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:
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.