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:
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:
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:
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:
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:
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:
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:
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:
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:
bpf: Validate nodeid in arenaallocpages()
arenaallocpages() accepts a plain int nodeid and forwards it through the entire allocation chain without any bounds checking.
Validate nodeid before passing it down the allocation chain in arenaallocpages().
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.
In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Reinstate disabling of BHs around IRQ handler
If the driver executes ks8851irq() AND a TX packet has been sent, then the driver enables TX queue via netifwakequeue() which schedules TX softirq to queue packets for this device.
If CONFIGPREEMPTRT=y is set AND a packet has also been received by the MAC, then ks8851rxpkts() calls netdevallocskbipalign() to allocate SKBs for the received packets. If netdevallocskbipalign() is called with BH enabled, then localbhenable() at the end of netdevallocskbipalign() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851startxmitpar(). The ks8851startxmitpar() will try to lock struct ks8851netpar .lock spinlock, which is already locked by ks8851irq() from which ks8851startxmitpar() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below.
If CONFIGPREEMPTRT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spinunlockbh(&ks->statelock) in ks8851irq(), which triggers the deadlock as well.
Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the nettxaction() softirq from triggering during these critical sections. The nettxaction() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed.
schedule from schedulertlock+0x1c/0x34 schedulertlock from rtlockslowlocklocked+0x548/0x904 rtlockslowlocklocked from rtspinlock+0x60/0x9c rtspinlock from ks8851startxmitpar+0x74/0x1a8 ks8851startxmitpar from netdevstartxmit+0x20/0x44 netdevstartxmit from devhardstartxmit+0xd0/0x188 devhardstartxmit from schdirectxmit+0xb8/0x25c schdirectxmit from qdiscrun+0x1f8/0x4ec qdiscrun from qdiscrun+0x1c/0x28 qdiscrun from nettxaction+0x1f0/0x268 nettxaction from handlesoftirqs+0x1a4/0x270 handlesoftirqs from localbhenableip+0xcc/0xe0 localbhenableip from allocskb+0xd8/0x128 allocskb from netdevallocskb+0x3c/0x19c netdevallocskb from ks8851irq+0x388/0x4d4 ks8851irq from irqthreadfn+0x24/0x64 irqthreadfn from irqthread+0x178/0x28c irqthread from kthread+0x12c/0x138 kthread from retfromfork+0x14/0x28
In the Linux kernel, the following vulnerability has been resolved:
octeonepvf: add NULL check for napibuildskb()
napibuildskb() can return NULL on allocation failure. In octepvfoqprocessrx(), the result is used directly without a NULL check in both the single-buffer and multi-fragment paths, leading to a NULL pointer dereference.
Add NULL checks after both napibuildskb() calls, properly advancing descriptors and consuming remaining fragments on failure.
In the Linux kernel, the following vulnerability has been resolved:
x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines
With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:
BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception
This small reproducer allows to easily trigger the crash:
# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1
Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:
sarq $5, %gs:x86calldepth(%rip)
This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of
59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):
it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.
As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.
Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.
[ bp: Massage. ]
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix bounds check for dcn35 DcfClocks
[Why] NumFclkLevelsEnabled is used for DcfClocks bounds check instead of designated NumDcfClkLevelsEnabled. That can cause array index out-of-bounds access.
[How] Use designated variable for dcn35 DcfClocks bounds check.
In the Linux kernel, the following vulnerability has been resolved:
tty: ngsm: fix possible out-of-bounds in gsm0receive()
Assuming the following: - side A configures the ngsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAXMRU in gsm0receive() and gsm1receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well.
Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic.
To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core).
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.