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:
tls: always refresh the queue when reading sock
After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.
BUG: KASAN: slab-use-after-free in tlsstrpcheckrcv+0x898/0x9a0 [tls] (net/tls/tlsstrp.c:436 net/tls/tlsstrp.c:530 net/tls/tlsstrp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529
CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasanreport+0xca/0x100 tlsstrpcheckrcv+0x898/0x9a0 [tls] tlsrxrecwait+0x2c9/0x8d0 [tls] tlsswrecvmsg+0x40f/0x1aa0 [tls] inetrecvmsg+0x1c3/0x1f0
Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.fulllen").
In the Linux kernel, the following vulnerability has been resolved:
9p: set req refcount to zero to avoid uninitialized usage
When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr.
If the p9readwork got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct.
Here is the logs from syzbot.
Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9fcallfini net/9p/client.c:248 [inline] p9reqput net/9p/client.c:396 [inline] p9reqput+0x208/0x250 net/9p/client.c:390 p9clientwalk+0x247/0x540 net/9p/client.c:1165 clonefid fs/9p/fid.h:21 [inline] v9fsfidxattrset+0xe4/0x2b0 fs/9p/xattr.c:118 v9fsxattrset fs/9p/xattr.c:100 [inline] v9fsxattrhandlerset+0x6f/0x120 fs/9p/xattr.c:159 vfssetxattr+0x119/0x180 fs/xattr.c:182 vfssetxattrnoperm+0x129/0x5f0 fs/xattr.c:216 vfssetxattrlocked+0x1d3/0x260 fs/xattr.c:277 vfssetxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 pathsetxattr+0x197/0x1c0 fs/xattr.c:636 dosyssetxattr fs/xattr.c:652 [inline] sesyssetxattr fs/xattr.c:648 [inline] ia32syssetxattr+0xc0/0x160 fs/xattr.c:648 dosyscall32irqson arch/x86/entry/common.c:112 [inline] dofastsyscall32+0x65/0xf0 arch/x86/entry/common.c:178 dofastsyscall32+0x33/0x70 arch/x86/entry/common.c:203 entrySYSENTERcompatafterhwframe+0x70/0x82
Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it.
T21124 p9readwork ======================== second trans ================================= p9clientwalk p9clientrpc p9clientpreparereq p9tagalloc req = kmemcachealloc(p9reqcache, GFPNOFS); tag = idralloc << preempted >> req->tc.tag = tag; / req->[refcount/tag] == uninitialized / m->rreq = p9taglookup(m->client, m->rc.tag); / increments uninitalized refcount /
refcountset(&req->refcount, 2); / cb drops one ref / p9clientcb(req) / reader thread drops its ref: request is incorrectly freed / p9reqput(req) / use after free and ref underflow / p9reqput(req)
To fix it, we can initialize the refcount to zero before add to idr.
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:
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
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:
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:
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.
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate buffer length while parsing index
indxread is called when we have some NTFS directory operations that need more information from the index buffers. This adds a sanity check to make sure the returned index buffer length is legit, or we may have some out-of-bound memory accesses.
[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdrfinde.isra.0+0x10c/0x320 [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245 [ 560.898760] [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37 [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 560.900170] Call Trace: [ 560.900407] <TASK> [ 560.900732] dumpstacklvl+0x49/0x63 [ 560.901108] printreport.cold+0xf5/0x689 [ 560.901395] ? hdrfinde.isra.0+0x10c/0x320 [ 560.901716] kasanreport+0xa7/0x130 [ 560.901950] ? hdrfinde.isra.0+0x10c/0x320 [ 560.902208] asanload2+0x68/0x90 [ 560.902427] hdrfinde.isra.0+0x10c/0x320 [ 560.902846] ? cmpuints+0xe0/0xe0 [ 560.903363] ? cmpsdh+0x90/0x90 [ 560.903883] ? ntfsbreadrun+0x190/0x190 [ 560.904196] ? rwsemdownreadslowpath+0x750/0x750 [ 560.904969] ? ntfsfixpostread+0xe0/0x130 [ 560.905259] ? kasancheckwrite+0x14/0x20 [ 560.905599] ? upread+0x1a/0x90 [ 560.905853] ? indxread+0x22c/0x380 [ 560.906096] indxfind+0x2ef/0x470 [ 560.906352] ? indxfindbuffer+0x2d0/0x2d0 [ 560.906692] ? kasankmalloc+0x88/0xb0 [ 560.906977] dirsearchu+0x196/0x2f0 [ 560.907220] ? ntfsnlstoutf16+0x450/0x450 [ 560.907464] ? kasancheckwrite+0x14/0x20 [ 560.907747] ? mutexlock+0x8f/0xe0 [ 560.907970] ? mutexlockslowpath+0x20/0x20 [ 560.908214] ? kmemcachealloc+0x143/0x4b0 [ 560.908459] ntfslookup+0xe0/0x100 [ 560.908788] lookupslow+0x116/0x220 [ 560.909050] ? lookupfast+0x1b0/0x1b0 [ 560.909309] ? lookupfast+0x13f/0x1b0 [ 560.909601] walkcomponent+0x187/0x230 [ 560.909944] linkpathwalk.part.0+0x3f0/0x660 [ 560.910285] ? handlelookupdown+0x90/0x90 [ 560.910618] ? pathinit+0x642/0x6e0 [ 560.911084] ? percpucounteraddbatch+0x6e/0xf0 [ 560.912559] ? allocfile+0x114/0x170 [ 560.913008] pathopenat+0x19c/0x1d10 [ 560.913419] ? getnameflags+0x73/0x2b0 [ 560.913815] ? kasansavestack+0x3a/0x50 [ 560.914125] ? kasansavestack+0x26/0x50 [ 560.914542] ? kasanslaballoc+0x6d/0x90 [ 560.914924] ? kmemcachealloc+0x143/0x4b0 [ 560.915339] ? getnameflags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? x64sysopen+0x4c/0x60 [ 560.916460] ? pathlookupat.isra.0+0x230/0x230 [ 560.916867] ? isolatefreepage+0x2e0/0x2e0 [ 560.917194] dofilpopen+0x15c/0x1f0 [ 560.917448] ? mayopendev+0x60/0x60 [ 560.917696] ? expandfiles+0xa4/0x3a0 [ 560.917923] ? kasancheckwrite+0x14/0x20 [ 560.918185] ? rawspinlock+0x88/0xdb [ 560.918409] ? rawspinlockirqsave+0x100/0x100 [ 560.918783] ? findnextbit+0x4a/0x130 [ 560.919026] ? rawspinunlock+0x19/0x40 [ 560.919276] ? allocfd+0x14b/0x2d0 [ 560.919635] dosysopenat2+0x32a/0x4b0 [ 560.920035] ? fileopenroot+0x230/0x230 [ 560.920336] ? rcureadunlock+0x5b/0x280 [ 560.920813] dosysopen+0x99/0xf0 [ 560.921208] ? filpopen+0x60/0x60 [ 560.921482] ? exittousermodeprepare+0x49/0x180 [ 560.921867] x64sysopen+0x4c/0x60 [ 560.922128] dosyscall64+0x3b/0x90 [ 560.922369] entrySYSCALL64afterhwframe+0x63/0xcd [ 560.923030] RIP: 0033:0x7f7dff2e4469 [ 560.923681] Code: 00 f3 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 088 [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIGRAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469 [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB reads parsing symlink error response
When a CREATE returns STATUSSTOPPEDONSYMLINK, smb2checkmessage() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server.
symlinkdata() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits.
smb2parsesymlinkresponse() then bounds-checks the substitute name using SMB2SYMLINKSTRUCTSIZE as the offset of PathBuffer from iovbase. That value is computed as sizeof(smb2errrsp) + sizeof(smb2symlinkerrrsp), which is correct only when ErrorContextCount == 0.
With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iovlen. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2).
Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset.
Because suboffs and sublen are 16bits, the pointer math will not overflow here with the new greater-than.
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, 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
fork: defer linking file vma until vma is fully initialized
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
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent ptregs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for ptregs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their ptregs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving taskptregs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smpcallin stored several registers on stack, corrupting top of ptregs structure including status field. As a result, kernel attempted to save or restore inexistent V context.