In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.
OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.
ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.
ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.
Initializing the whole thing before parsing is needed because ND packet may not contain all the options.
The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate payload size in ipc response
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.
In the Linux kernel, the following vulnerability has been resolved:
keys: Fix overwrite of key expiration on instantiation
The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64MAX, disabling further DNS updates. Fix this by restoring the condition that keysetexpiry is only called when the pre-parser sets a specific expiry.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix potential glock use-after-free on unmount
The Linux kernel CVE team has assigned CVE-2024-38570 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024061956-CVE-2024-38570-a8ef@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in ofmodalias()
In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxecompqueuepkt
In rxecompqueuepkt() an incoming response packet skb is enqueued to the resppkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix invalid unregister error path
The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.
This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.
In the Linux kernel, the following vulnerability has been resolved:
Revert "xsk: Support redirect to any socket bound to the same umem"
This reverts commit 2863d665ea41282379f108e4da6c8a2366ba66db.
This patch introduced a potential kernel crash when multiple napi instances redirect to the same AFXDP socket. By removing the queueindex check, it is possible for multiple napi instances to access the Rx ring at the same time, which will result in a corrupted ring state which can lead to a crash when flushing the rings in xskflush(). This can happen when the linked list of sockets to flush gets corrupted by concurrent accesses. A quick and small fix is not possible, so let us revert this for now.
In the Linux kernel, the following vulnerability has been resolved:
ionic: fix kernel panic in XDPTX action
In the XDPTX path, ionic driver sends a packet to the TX path with rx page and corresponding dma address. After tx is done, ionictxclean() frees that page. But RX ring buffer isn't reset to NULL. So, it uses a freed page, which causes kernel panic.
BUG: unable to handle page fault for address: ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11 Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bpfprogf0b8caeac1068a55balanceringress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x20/0x70 ? pagefaultoops+0x254/0x790 ? pfxpagefaultoops+0x10/0x10 ? pfxisprefetch.constprop.0+0x10/0x10 ? searchbpfextables+0x165/0x260 ? fixupexception+0x4a/0x970 ? excpagefault+0xcb/0xe0 ? asmexcpagefault+0x22/0x30 ? 0xffffffffc0051f64 ? bpfprogf0b8caeac1068a55balanceringress+0x3b/0x44f ? dorawspinunlock+0x54/0x220 ionicrxservice+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionictxclean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? pfxionictxclean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? pfxionicrxservice+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionictxcqservice+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? pfxionicrxservice+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ioniccqservice+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionictxrxnapi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] napipoll.constprop.0+0xa0/0x440 netrxaction+0x7e7/0xc30 ? pfxnetrxaction+0x10/0x10
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfsd4deleggetattrconflict in presence of third party lease
It is not safe to dereference fl->c.flcowner without first confirming fl->fllmops is the expected manager. nfsd4deleggetattrconflict() tests fllmops but largely ignores the result and assumes that flcowner is an nfs4delegation anyway. This is wrong.
With this patch we restore the "!= &nfsdleasemngops" case to behave as it did before the change mentioned below. This is the same as the current code, but without any reference to a possible delegation.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix potential UAF in nfsd4cbgetattrrelease
Once we drop the delegation reference, the fields embedded in it are no longer safe to access. Do that last.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double put of @cfile in smb2renamepath()
If smb2setpathattr() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritablepath() again as the reference of @cfile was already dropped by previous smb2compoundop() call.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double put of @cfile in smb2setpathsize()
If smb2compoundop() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritablepath() before retrying it as the reference of @cfile was already dropped by previous call.
This fixes the following KASAN splat when running fstests generic/013 against Windows Server 2022:
CIFS: Attempting to mount //w22-fs0/scratch run fstests generic/013 at 2024-09-02 19:48:59 ================================================================== BUG: KASAN: slab-use-after-free in detachifpending+0xab/0x200 Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176
CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: cifsoplockd cifsoplockbreak [cifs] Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? detachifpending+0xab/0x200 printreport+0x156/0x4d9 ? detachifpending+0xab/0x200 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? detachifpending+0xab/0x200 kasanreport+0xda/0x110 ? detachifpending+0xab/0x200 detachifpending+0xab/0x200 timerdelete+0x96/0xe0 ? pfxtimerdelete+0x10/0x10 ? rcuiswatching+0x20/0x50 trytograbpending+0x46/0x3b0 cancelwork+0x89/0x1b0 ? pfxcancelwork+0x10/0x10 ? kasansavetrack+0x14/0x30 cifsclosedeferredfile+0x110/0x2c0 [cifs] ? pfxcifsclosedeferredfile+0x10/0x10 [cifs] ? pfxdownread+0x10/0x10 cifsoplockbreak+0x4c1/0xa50 [cifs] ? pfxcifsoplockbreak+0x10/0x10 [cifs] ? lockisheldtype+0x85/0xf0 ? markheldlocks+0x1a/0x90 processonework+0x4c6/0x9f0 ? findheldlock+0x8a/0xa0 ? pfxprocessonework+0x10/0x10 ? lockacquired+0x220/0x550 ? listaddvalidorreport+0x37/0x100 workerthread+0x2e4/0x570 ? kthreadparkme+0xd1/0xf0 ? pfxworkerthread+0x10/0x10 kthread+0x17f/0x1c0 ? kthread+0xda/0x1c0 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 1118: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0xaa/0xb0 cifsnewfileinfo+0xc8/0x9d0 [cifs] cifsatomicopen+0x467/0x770 [cifs] lookupopen.isra.0+0x665/0x8b0 pathopenat+0x4c3/0x1380 dofilpopen+0x167/0x270 dosysopenat2+0x129/0x160 x64syscreat+0xad/0xe0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 83: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 poisonslabobject+0xe9/0x160 kasanslabfree+0x32/0x50 kfree+0xf2/0x300 processonework+0x4c6/0x9f0 workerthread+0x2e4/0x570 kthread+0x17f/0x1c0 retfromfork+0x31/0x60 retfromforkasm+0x1a/0x30
Last potentially related work creation: kasansavestack+0x30/0x50 kasanrecordauxstack+0xad/0xc0 insertwork+0x29/0xe0 queuework+0x5ea/0x760 queueworkon+0x6d/0x90 cifsFileInfoput+0x3f6/0x770 [cifs] smb2compoundop+0x911/0x3940 [cifs] smb2setpathsize+0x228/0x270 [cifs] cifssetfilesize+0x197/0x460 [cifs] cifssetattr+0xd9c/0x14b0 [cifs] notifychange+0x4e3/0x740 dotruncate+0xfa/0x180 vfstruncate+0x195/0x200 x64systruncate+0x109/0x150 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix possible badness in FREESTATEID
When multiple FREESTATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors.
In nfsd4freestateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4putstid(), that allows another FREESTATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in durable v2 replay of active file handles
parsedurablehandlecontext() unconditionally assigns dhinfo->fp->conn to the current connection when handling a DURABLEREQV2 context with SMB2FLAGSREPLAYOPERATION. ksmbdlookupfdcguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, ksmbdclosefd() dereferences the stale fp->conn via spinlock(&fp->conn->llistlock), causing a use-after-free.
KASAN report:
[ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in rawspinlock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 7.350070] Workqueue: ksmbd-io handleksmbdwork [ 7.350083] Call Trace: [ 7.350087] <TASK> [ 7.350087] dumpstacklvl+0x64/0x80 [ 7.350094] printreport+0xce/0x660 [ 7.350100] ? pfxrawspinlockirqsave+0x10/0x10 [ 7.350101] ? pfxmodtimer+0x10/0x10 [ 7.350106] ? rawspinlock+0x75/0xe0 [ 7.350108] kasanreport+0xce/0x100 [ 7.350109] ? rawspinlock+0x75/0xe0 [ 7.350114] kasancheckrange+0x105/0x1b0 [ 7.350116] rawspinlock+0x75/0xe0 [ 7.350118] ? pfxrawspinlock+0x10/0x10 [ 7.350119] ? callrcucommon.constprop.0+0x25e/0x780 [ 7.350125] ? closeiddeloplock+0x2cc/0x4e0 [ 7.350128] ksmbdclosefd+0x27f/0xaf0 [ 7.350131] ksmbdclosefd+0x135/0x1b0 [ 7.350133] smb2close+0xb19/0x15b0 [ 7.350142] ? pfxsmb2close+0x10/0x10 [ 7.350143] ? xasload+0x18/0x270 [ 7.350146] ? rawspinlock+0x84/0xe0 [ 7.350148] ? pfxrawspinlock+0x10/0x10 [ 7.350150] ? rawspinunlock+0xe/0x30 [ 7.350151] ? ksmbdsmb2checkmessage+0xeb2/0x24c0 [ 7.350153] ? ksmbdtreeconnlookup+0xcd/0xf0 [ 7.350154] handleksmbdwork+0x40f/0x1080 [ 7.350156] processonework+0x5fa/0xef0 [ 7.350162] ? assignwork+0x122/0x3e0 [ 7.350163] workerthread+0x54b/0xf70 [ 7.350165] ? pfxworkerthread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalcsigpending+0x19b/0x230 [ 7.350176] ? pfxkthread+0x10/0x10 [ 7.350178] retfromfork+0x4fb/0x6c0 [ 7.350183] ? pfxretfromfork+0x10/0x10 [ 7.350185] ? switchto+0x36c/0xbe0 [ 7.350188] ? pfxkthread+0x10/0x10 [ 7.350190] retfromforkasm+0x1a/0x30 [ 7.350197] </TASK> [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasansavestack+0x33/0x60 [ 7.355373] kasansavetrack+0x14/0x30 [ 7.355484] kasankmalloc+0x8f/0xa0 [ 7.355593] ksmbdconnalloc+0x44/0x6d0 [ 7.355711] ksmbdkthreadfn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] retfromfork+0x4fb/0x6c0 [ 7.356051] retfromforkasm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasansavestack+0x33/0x60 [ 7.356416] kasansavetrack+0x14/0x30 [ 7.356527] kasansavefreeinfo+0x3b/0x60 [ 7.356646] kasanslabfree+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbdtcpdisconnect+0x59/0xe0 [ 7.356993] ksmbdconnhandlerloop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] retfromfork+0x4fb/0x6c0 [ 7.357350] retfromforkasm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbdclosefd() via durable scavenger
When a durable file handle survives session disconnect (TCP close without SMB2LOGOFF), sessionfdcheck() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->locklist.
Later, when the durable scavenger thread times out and calls ksmbdclosefd(NULL, fp), the lock cleanup loop did:
spinlock(&fp->conn->llistlock);
This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbdtcpdisconnect().
The root cause is asymmetric cleanup: lock entries (smblock->clist) were left dangling on the freed conn->locklist while fp->conn was nulled out.
To fix this issue properly, we need to handle the lifetime of smblock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's locklist in sessionfdcheck() - Re-add the lock to the new connection's locklist in ksmbdreopendurablefd().
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Completely fix fcport double free
In qla24xxelsdcmdiocb() sp->free is set to qla2x00elsdcmdspfree(). When an error happens, this function is called by qla2x00sprelease(), when krefput() releases the first and the last reference.
qla2x00elsdcmdspfree() frees fcport by calling qla2x00freefcport(). Doing it one more time after krefput() is a bad idea.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smblazyparentleasebreakclose()
opinfo pointer obtained via rcudereference(fp->fopinfo) is being accessed after rcureadunlock() has been called. This creates a race condition where the memory could be freed by a concurrent writer between the unlock and the subsequent pointer dereferences (opinfo->islease, etc.), leading to a use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2open during durable reconnect
In smb2open, the call to ksmbdputdurablefd(fp) drops the reference to the durable file descriptor early during the durable reconnect process. If an error occurs subsequently (eg, ksmbdiovpinrsp fails) or a scavenger accesses the file, it leads to a use-after-free when accessing fp properties (eg fp->createtime).
Move the single put to the end of the function below errout2 so fp stays valid until smb2open returns.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: refresh hdr pointer before ioam6event()
Reported by Sashiko:
In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:
if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;
/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));
ioam6filltracedata(skb, ns, trace, true);
ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);
If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.
This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.
In the Linux kernel, the following vulnerability has been resolved:
smb/client: fix out-of-bounds read in smb2compoundop()
If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, checkwsleas() returns success without validating that the entire OutputBufferLength fits within iovlen.
Then smb2compoundop() does: memcpy(idata->wsl.eas, data[0], size[0]);
Where size[0] is OutputBufferLength. If iovlen is smaller than size[0], memcpy can read beyond the end of the rspiov allocation and leak adjacent kernel heap memory.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix NULL module pointer assignment at card init
The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARNON() for a NULL module pointer passed at sndcard object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIGSND=y) while the driver is a module (CONFIGSNDUSBAUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal.
For addressing the bug, move the assignment of card->module again out of ifdef. The WARNON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.
Note that we keep 'ifdef MODULE' for WARNON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIGSND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.
Bluetooth: HCI: Remove HCIAMP support
In the Linux kernel, the following vulnerability has been resolved:
iommu: Restore lost return in iommureportdevicefault()
When iommureportdevicefault gets called with a partial fault it is supposed to collect the fault into the group and then return.
Instead the return was accidently deleted which results in trying to process the fault and an eventual crash.
Deleting the return was a typo, put it back.
In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in more places
For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmdcfgpkts") makes tx() calling devput() instead of doing in aoecmdcfgpkts(). It avoids that the tx() runs into use-after-free.
Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmdatarw(), resend(), probe() and aoecmdcfgrsp(). Those functions also use aoenetxmit() to push packet to tx queue. So they should also use devhold() to increase the refcnt of skb->dev.
On the other hand, moving devput() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding devhold() are not called in revalidate(), aoecmdatarw(), resend(), probe(), and aoecmdcfgrsp(). This patch fixed this issue.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxustaadd
The driver does not set hw->stadatasize, which causes mac80211 to allocate insufficient space for driver private station data in stainfoalloc(). When rtl8xxxustaadd() accesses members of struct rtl8xxxustainfo through sta->drvpriv, this results in a slab-out-of-bounds write.
KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:
BUG: KASAN: slab-out-of-bounds in rtl8xxxustaadd+0x31c/0x346 Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12
Set hw->stadatasize to sizeof(struct rtl8xxxustainfo) during probe, similar to how hw->vifdatasize is configured. This ensures mac80211 allocates sufficient space for the driver's per-station private data.
Tested on StarFive VisionFive 2 v1.2A board.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate owner of durable handle on reconnect
Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.
According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2CREATE (DHnC).
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:
iio: pressure: mprls0025pa: fix spitransfer struct initialisation
Make sure that the spitransfer struct is zeroed out before use.
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: re-fix fortified-memset warning
The carl9170txrelease() function sometimes triggers a fortified-memset warning in my randconfig builds:
In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortifymemsetchk', inlined from 'carl9170txrelease' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'krefput' at include/linux/kref.h:65:3, inlined from 'carl9170txputskb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to 'writeoverflowfield' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use structgroup()? [-Werror=attribute-warning] 493 | writeoverflowfield(psizefield, size);
Kees previously tried to avoid this by using memsetafter(), but it seems this does not fully address the problem. I noticed that the memsetafter() here is done on a different part of the union (status) than the original cast was from (ratedriverdata), which may confuse the compiler.
Unfortunately, the memsetafter() trick does not work on driverrates[] because that is part of an anonymous struct, and I could not get structgroup() to do this either. Using two separate memset() calls on the two members does address the warning though.