In the Linux kernel, the following vulnerability has been resolved:
crypto: safexcel - Add error handling for dmamapsg() calls
Macro dmamapsg() may return 0 on error. This patch enables checks in case of the macro failure and ensures unmapping of previously mapped buffers with dmaunmapsg().
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
In the Linux kernel, the following vulnerability has been resolved:
smb: During unmount, ensure all cached dir instances drop their dentry
The unmount process (cifskillsb() calling closeallcacheddirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:
BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!
This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:
- Receiving a lease break from the server - Server reconnection triggers invalidateallcacheddirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid.
To solve these problems, dropping the dentry is done in queued work done in a newly-added cfidputwq workqueue, and closeallcacheddirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.
The final cleanup work for cleaning up a cfid is performed via work queued in the serverclosewq workqueue; this is done separate from dropping the dentries so that closeallcacheddirs() doesn't block on any server operations.
Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.
While we're here, add proper locking to closeallcacheddirs(), and locking around the freeing of cfid->dentry.
In the Linux kernel, the following vulnerability has been resolved:
drm/display/dpmst: Add protection against 0 vcpi
When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayeddestroywork ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0.
Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drmdpmstgetportmalloc [drmdisplayhelper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drmdpmsttopology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPUOUTOFSPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drmdpmstwq drmdpdelayeddestroywork [drmdisplayhelper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dumpstacklvl+0xc1/0xf0 <4> [515.287313] dumpstack+0x10/0x20 <4> [515.287316] ubsanhandleshiftoutofbounds+0x133/0x2e0 <4> [515.287324] ? drmatomicgetprivateobjstate+0x186/0x1d0 <4> [515.287333] drmdpatomicreleasetimeslots.cold+0x17/0x3d [drmdisplayhelper] <4> [515.287355] mstconnectoratomiccheck+0x159/0x180 [xe] <4> [515.287546] drmatomichelpercheckmodeset+0x4d9/0xfa0 <4> [515.287550] ? wwmutexlock.constprop.0+0x6f/0x1a60 <4> [515.287562] intelatomiccheck+0x119/0x2b80 [xe] <4> [515.287740] ? findheldlock+0x31/0x90 <4> [515.287747] ? lockrelease+0xce/0x2a0 <4> [515.287754] drmatomiccheckonly+0x6a2/0xb40 <4> [515.287758] ? drmatomicaddaffectedconnectors+0x12b/0x140 <4> [515.287765] drmatomiccommit+0x6e/0xf0 <4> [515.287766] ? pfxdrmprintfninfo+0x10/0x10 <4> [515.287774] drmclientmodesetcommitatomic+0x25c/0x2b0 <4> [515.287794] drmclientmodesetcommitlocked+0x60/0x1b0 <4> [515.287795] ? mutexlocknested+0x1b/0x30 <4> [515.287801] drmclientmodesetcommit+0x26/0x50 <4> [515.287804] drmfbhelperrestorefbdevmodeunlocked+0xdc/0x110 <4> [515.287810] drmfbhelperhotplugevent+0x120/0x140 <4> [515.287814] drmfbdevclienthotplug+0x28/0xd0 <4> [515.287819] drmclienthotplug+0x6c/0xf0 <4> [515.287824] drmclientdevhotplug+0x9e/0xd0 <4> [515.287829] drmkmshelperhotplugevent+0x1a/0x30 <4> [515.287834] drmdpdelayeddestroywork+0x3df/0x410 [drmdisplayhelper] <4> [515.287861] processonework+0x22b/0x6f0 <4> [515.287874] workerthread+0x1e8/0x3d0 <4> [515.287879] ? pfxworkerthread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? pfxkthread+0x10/0x10 <4> [515.287890] retfromfork+0x2d7/0x310 <4> [515.287894] ? pfxkthread+0x10/0x10 <4> [515.287897] retfromforkasm+0x1a/0x30
A deouble-free flaw in the Linux Kernel Intel GVT-g graphics driver found. The problem happens when some system resource on high cost. One way to trigger is to make dma high load. When it gets into the situation when function intelgvtdmamapguestpage failed, the flaw being triggered.
Reference: https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz@163.com/
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix SECINFONONAME decode error cleanup
nfsd4decodesecinfononame() currently initializes sinexp after decoding sinstyle. If the XDR stream is truncated, the decoder returns nfserrbadxdr before sinexp is initialized.
Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFONONAME decode can therefore leave sinexp holding stale union contents from a previous operation.
The error response path still invokes nfsd4secinfononamerelease(), which calls expput() on a non-NULL sinexp.
Initialize sinexp before the first failable decode step, matching nfsd4decodesecinfo().
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hciconn: Fix UAF in hcienhancedsetupsync
This checks if the ACL connection remains valid as it could be destroyed while hcienhancedsetupsync is pending on cmdsync leading to the following trace:
BUG: KASAN: slab-use-after-free in hcienhancedsetupsync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37
CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? hcienhancedsetupsync+0x91b/0xa60 printreport+0x152/0x4c0 ? hcienhancedsetupsync+0x91b/0xa60 ? virtaddrvalid+0x1fa/0x420 ? hcienhancedsetupsync+0x91b/0xa60 kasanreport+0xda/0x1b0 ? hcienhancedsetupsync+0x91b/0xa60 hcienhancedsetupsync+0x91b/0xa60 ? pfxhcienhancedsetupsync+0x10/0x10 ? pfxmutexlock+0x10/0x10 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 ? pfxlockacquire+0x10/0x10 ? pfxprocessonework+0x10/0x10 ? assignwork+0x167/0x240 workerthread+0x5b7/0xf60 ? kthreadparkme+0xac/0x1c0 ? pfxworkerthread+0x10/0x10 ? pfxworkerthread+0x10/0x10 kthread+0x293/0x360 ? pfxkthread+0x10/0x10 retfromfork+0x2f/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 34: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 hciconnadd+0x187/0x17d0 hciconnectsco+0x2e1/0xb90 scosockconnect+0x2a2/0xb80 sysconnect+0x227/0x2a0 x64sysconnect+0x6d/0xb0 dosyscall64+0x71/0x140 entrySYSCALL64afterhwframe+0x76/0x7e
Freed by task 37: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x101/0x160 kfree+0xd0/0x250 devicerelease+0x9a/0x210 kobjectput+0x151/0x280 hciconndel+0x448/0xbf0 hciabortconnsync+0x46f/0x980 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 workerthread+0x5b7/0xf60 kthread+0x293/0x360 retfromfork+0x2f/0x70 retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: update channel list in reg notifier instead reg worker
Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue regwork. 2. cfg80211 handles new channel list during regwork. 3. update cfg80211's handled channel list to firmware by ath11kregupdatechanlist().
But ath11k will immediately execute step 3 after regwork is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11kregupdatechanlist Call Trace: ath11kregupdatechanlist+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11kregdupdate+0x1cf/0x350 [ath11k] ath11kregdupdatework+0x14/0x20 [ath11k] processonework+0xe35/0x14c0
Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211REGDOMSETBYDRIVER is set, cfg80211 will notify ath11k after step 2 is done.
So enable the flag NL80211REGDOMSETBYDRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3.
[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quicwgong@quicinc.com/
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception
Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).
This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:
1) Creating a KVM VM and vCPU 2) Sending a KVMSMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault
The issue manifests as follows:
WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdowninterception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svminvokeexithandler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svmhandleexit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpuenterguest arch/x86/kvm/x86.c:10959 [inline] vcpurun+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvmarchvcpuioctlrun+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvmvcpuioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvmmain.c:4122 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:870 [inline] sesysioctl fs/ioctl.c:856 [inline] x64sysioctl+0x19a/0x210 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8
Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvmvcpureset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do something sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.
So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
[sean: massage changelog, make it clear this isn't architectural behavior]
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash when I/O abort times out
While performing CPU hotplug, a crash with the following stack was seen:
Call Trace: qla24xxprocessresponsequeue+0x42a/0x970 [qla2xxx] qla2x00startnvmemq+0x3a2/0x4b0 [qla2xxx] qlanvmepostcmd+0x166/0x240 [qla2xxx] nvmefcstartfcpop.part.0+0x119/0x2e0 [nvmefc] blkmqdispatchrqlist+0x17b/0x610 blkmqscheddispatchrequests+0xb0/0x140 blkmqscheddispatchrequests+0x30/0x60 blkmqrunhwqueue+0x35/0x90 blkmqdelayrunhwqueue+0x161/0x180 blkexecuterq+0xbe/0x160 nvmesubmitsynccmd+0x16f/0x220 [nvmecore] nvmfconnectadminqueue+0x11a/0x170 [nvmefabrics] nvmefccreateassociation.cold+0x50/0x3dc [nvmefc] nvmefcconnectctrlwork+0x19/0x30 [nvmefc] processonework+0x1e8/0x3c0
On abort timeout, completion was called without checking if the I/O was already completed.
Verify that I/O and abort request are indeed outstanding before attempting completion.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: split cachedfid bitfields to avoid shared-byte RMW races
isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.
A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits
To avoid this class of races, convert these flags to separate bool fields.
In the Linux kernel, the following vulnerability has been resolved:
kernfs: Fix UAF in polling when open file is released
A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism:
BUG: KASAN: slab-use-after-free in psitriggerpoll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1
psitriggerpoll+0x3c/0x140 cgrouppressurepoll+0x70/0xa0 cgroupfilepoll+0x8c/0x100 kernfsfoppoll+0x11c/0x1c0 epitempoll.isra.0+0x188/0x2c0
Allocated by task 1: cgroupfileopen+0x88/0x388 kernfsfopopen+0x73c/0xaf0 dodentryopen+0x5fc/0x1200 vfsopen+0xa0/0x3f0 doopen+0x7e8/0xd08 pathopenat+0x2fc/0x6b0 dofilpopen+0x174/0x368
Freed by task 8462: cgroupfilerelease+0x130/0x1f8 kernfsdrainopenfiles+0x17c/0x440 kernfsdrain+0x2dc/0x360 kernfsshow+0x1b8/0x288 cgroupfileshow+0x150/0x268 cgrouppressurewrite+0x1dc/0x340 cgroupfilewrite+0x274/0x548
Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure
The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroupfilerelease() - Frees of->priv through kernfsdrainopenfiles() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv
epolling disable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epollwait kernfsfoppoll kernfsgetactive = true echo 0 > cgroup.pressure ... cgroupfileshow kernfsshow // inactive kn kernfsdrainopenfiles cft->release(of); kfree(ctx); ... kernfsgetactive = false echo 1 > cgroup.pressure kernfsshow kernfsactivateone(kn); kernfsfoppoll kernfsgetactive = true cgroupfilepoll psitriggerpoll // UAF ... end: close(fd)
To address this issue, introduce kernfsgetactiveof() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfsgetactive() with kernfsgetactiveof() to prevent further operations on released file descriptors.
In the Linux kernel, the following vulnerability has been resolved:
misc: microchip: pci1xxxx: fix double free in the error handling of gpauxbusprobe()
When auxiliarydeviceadd() returns error and then calls auxiliarydeviceuninit(), callback function gpauxiliarydevicerelease() calls idafree() and kfree(auxdevicewrapper) to free memory. We should't call them again in the error handling path.
Fix this by skipping the redundant cleanup functions.
In the Linux kernel, the following vulnerability has been resolved:
kdb: Fix buffer overflow during tab-complete
Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.
cgroup/rstat: validate cpu before cssrstatcpu() access
In the Linux kernel, the following vulnerability has been resolved:
lockd: set other missing fields when unlocking files
vfslockfile() expects the struct filelock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the flfile field is NULL.
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between loginwork and the login thread
In case a malicious initiator sends some random data immediately after a login PDU; the iscsitargetskdataready() callback will schedule the loginwork and, at the same time, the negotiation may end without clearing the LOGINFLAGSINITIALPDU flag (because no additional PDU exchanges are required to complete the login).
The login has been completed but the loginwork function will find the LOGINFLAGSINITIALPDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsitconn structure will be freed, loginwork will dereference a released socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: errorcode(0x0002) - not-present page Workqueue: events iscsitargetdologinrx [iscsitargetmod] RIP: 0010:rawreadlockbh+0x15/0x30 Call trace: iscsitargetdologinrx+0x75/0x3f0 [iscsitargetmod] processonework+0x1e8/0x3c0
Fix this bug by forcing loginwork to stop after the login has been completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsitargetdologin()
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwlmvmndmatchinfohandler()
The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.
The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.
We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
In the Linux kernel before 6.1.3, fs/ntfs3/record.c does not validate resident attribute names. An out-of-bounds write may occur.
In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Prevent out-of-bounds memory access
The testtag test triggers an unhandled page fault:
# ./testtag [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: testtag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 buildbody+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c buildbody+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last unloaded: bpftestmod(O)] [ 130.642924] Process testtag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call Trace: [ 130.644641] [<9000000003137f7c>] buildbody+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpfintjitcompile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpfprogselectruntime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpfprogload+0x760/0xb44 [ 130.645089] [<90000000032b6744>] sysbpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sysbpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] dosyscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handlesyscall+0xbc/0x158 [ 130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]---
On my machine, which has CONFIGPAGESIZE16KB=y, the test failed at loading a BPF prog with 2039 instructions:
prog = (struct bpfprog )ffff80001b894000 insn = (struct bpfinsn )(prog->insnsi)fff ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix out-of-bounds memory access
Fix a bug that pdata->cpumap[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.
In the Linux kernel, the following vulnerability has been resolved:
lan966x: Fix crash when adding interface under a lag
There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0
The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: proper TCATAPRIOTCENTRYINDEX check
taprioparsetcentry() is not correctly checking TCATAPRIOTCENTRYINDEX attribute:
int tc; // Signed value
tc = nlagetu32(tb[TCATAPRIOTCENTRYINDEX]); if (tc >= TCQOPTMAXQUEUE) { NLSETERRMSGMOD(extack, "TC entry index out of range"); return -ERANGE; }
syzbot reported that it could fed arbitary negative values:
UBSAN: shift-out-of-bounds in net/sched/schtaprio.c:1722:18 shift exponent -2147418108 is negative CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2e0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] ubsanhandleshiftoutofbounds+0x3c7/0x420 lib/ubsan.c:386 taprioparsetcentry net/sched/schtaprio.c:1722 [inline] taprioparsetcentries net/sched/schtaprio.c:1768 [inline] tapriochange+0xb87/0x57d0 net/sched/schtaprio.c:1877 taprioinit+0x9da/0xc80 net/sched/schtaprio.c:2134 qdisccreate+0x9d4/0x1190 net/sched/schapi.c:1355 tcmodifyqdisc+0xa26/0x1e40 net/sched/schapi.c:1776 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6617 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2584 syssendmsg net/socket.c:2638 [inline] syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340 R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340
In the Linux kernel, the following vulnerability has been resolved:
freezer,umh: Fix callusermodehelperexec() vs SIGKILL
Tetsuo-San noted that commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") broke callusermodehelperexec() for the KILLABLE case.
Specifically it was missed that the second, unconditional, waitforcompletion() was not optional and ensures the on-stack completion is unused before going out-of-scope.
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix vf may be used uninitialized in this function warning
The Linux kernel CVE team has assigned CVE-2024-36020 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053044-CVE-2024-36020-5da7@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: Wait unconditionally after issuing EndXfer command
Currently all controller IP/revisions except DWC3usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWCusb3 controller revisions >= 3.10a supports GUCTL2[14: Rstactbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed.
Consider a case where an IN request was queued, and parallelly softdisconnect was called (due to ffsepfilerelease). This eventually calls stopactivetransfer with IOC cleared, hence sendgadgetepcmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests.
Fix this by ensuring ENDXFER completion by adding 1ms delay in dwc3stopactivetransfer() unconditionally.
In the Linux kernel, the following vulnerability has been resolved:
efi: libstub: only free priv.runtimemap when allocated
priv.runtimemap is only allocated when efinovamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to freepool. Free priv.runtimemap only when it was allocated.
This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
dma-mapping: benchmark: handle NUMANONODE correctly