In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status
Check kvmmmupageadneedwriteprotect() when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU accounts for any role-specific reasons for disabling D-bit dirty logging.
Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled. KVM always disables PML when running L2, even when L1 and L2 GPAs are in the some domain, so failing to write-protect TDP MMU SPTEs will cause writes made by L2 to not be reflected in the dirty log.
[sean: massage shortlog and changelog, tweak ternary op formatting]
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumacltcam: Fix possible use-after-free during rehash
The Linux kernel CVE team has assigned CVE-2024-35854 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Fix double free of skb in coredump
hcidevcdappend() would free the skb on error so the caller don't have to free it again otherwise it would cause the double free of skb.
Reported-by : Dan Carpenter <dan.carpenter@linaro.org>
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. ismoduletextaddress() and moduletextaddress() works with MODULESTATELIVE and MODULESTATEGOING. If we use ismoduletextaddress() and moduletextaddress() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.
In checkkprobeaddresssafe(), if the second moduletextaddress() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).
To fix this problem, we should not use separated ismoduletextaddress() and moduletextaddress(), but use only moduletextaddress() once and do trymoduleget(module) which is only available with MODULESTATELIVE.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6getifaddr and ipv6deladdr
Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (in6ifaput(ifp) + in6ifaput(ifp)). With bad enough timing, this can happen:
1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.
2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfreercu is scheduled.
3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.
[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] syssendto+0x1d8/0x1f0 [ 41.525145] x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64afterhwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2capconnect()
Extend a critical section to prevent chan from early freeing. Also make the l2capconnect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix.
Call stack summary:
[use] l2capbredrsigcmd l2capconnect ┌ mutexlock(&conn->chanlock); │ chan = pchan->ops->newconnection(pchan); <- alloc chan │ l2capchanadd(conn, chan); │ l2capchanhold(chan); │ listadd(&chan->list, &conn->chanl); ... (1) └ mutexunlock(&conn->chanlock); chan->confstate ... (4) <- use after free
[free] l2capconndel ┌ mutexlock(&conn->chanlock); │ foreach chan in conn->chanl: ... (2) │ l2capchanput(chan); │ l2capchandestroy │ kfree(chan) ... (3) <- chan freed └ mutexunlock(&conn->chanlock);
================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicread include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2capconnect+0xa67/0x11a0 net/bluetooth/l2capcore.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.
In the Linux kernel, the following vulnerability has been resolved:
bcachefs: Check for journal entries overruning end of sb clean section
Fix a missing bounds check in superblock validation.
Note that we don't yet have repair code for this case - repair code for individual items is generally low priority, since the whole superblock is checksummed, validated prior to write, and we have backups.
In the Linux kernel, the following vulnerability has been resolved:
arm64: tlb: Fix TLBI RANGE operand
KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvmtlbflushvmidrange()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed.
For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvmtlbflushvmidrange() is executed to flush TLBs. It passes MAXTLBIRANGEPAGES as the argument to kvmtlbflushvmidrange() and flushs2tlbrangeop(). SCALE#3 and NUM#31, corresponding to MAXTLBIRANGEPAGES, isn't supported by TLBIRANGENUM(). In this specific case, -1 has been returned from TLBIRANGENUM() for SCALE#3/2/1/0 and rejected by the loop in the flushtlbrangeop() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by TLBIVADDRRANGE() according to invalid @scale and @num.
Fix it by extending TLBIRANGENUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBIRANGEMASK is dropped since no one uses it any more. The comments are also adjusted accordingly.
In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix loading 64-bit NOMMU kernels past the start of RAM
commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") added logic to allow using RAM below the kernel load address. However, this does not work for NOMMU, where PAGEOFFSET is fixed to the kernel load address. Since that range of memory corresponds to PFNs below ARCHPFNOFFSET, mm initialization runs off the beginning of memmap and corrupts adjacent kernel memory. Fix this by restoring the previous behavior for NOMMU kernels.
In the Linux kernel, the following vulnerability has been resolved:
uiohvgeneric: Don't free decrypted memory
In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
The VMBus device UIO driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2allocaterspbuf()
The response buffer should be allocated in smb2allocaterspbuf before validating request. But the fields in payload as well as smb2 header is used in smb2allocaterspbuf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: brnetfilter: skip conntrack input hook for promisc packets
For historical reasons, when bridge device is in promisc mode, packets that are directed to the taps follow bridge input hook path. This patch adds a workaround to reset conntrack for these packets.
Jianbo Liu reports warning splats in their test infrastructure where cloned packets reach the brnetfilter input hook to confirm the conntrack object.
Scratch one bit from BRINPUTSKBCB to annotate that this packet has reached the input hook because it is passed up to the bridge device to reach the taps.
[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/brnetfilterhooks.c:616 brnflocalin+0x157/0x180 [brnetfilter] [ 57.572749] Modules linked in: xtMASQUERADE nfconntracknetlink nfnetlink iptablenat xtaddrtype xtconntrack nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportisc si ibumad rdmacm ibipoib iwcm ibcm mlx5ib ibuverbs ibcore mlx5ctl mlx5core [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19 [ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 57.576662] RIP: 0010:brnflocalin+0x157/0x180 [brnetfilter] [ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1 [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202 [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000 [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000 [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003 [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000 [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800 [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000 [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0 [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 57.585440] Call Trace: [ 57.585721] <IRQ> [ 57.585976] ? warn+0x7d/0x130 [ 57.586323] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.586811] ? reportbug+0xf1/0x1c0 [ 57.587177] ? handlebug+0x3f/0x70 [ 57.587539] ? excinvalidop+0x13/0x60 [ 57.587929] ? asmexcinvalidop+0x16/0x20 [ 57.588336] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.588825] nfhookslow+0x3d/0xd0 [ 57.589188] ? brhandlevlan+0x4b/0x110 [ 57.589579] brpassframeup+0xfc/0x150 [ 57.589970] ? brportflagschange+0x40/0x40 [ 57.590396] brhandleframefinish+0x346/0x5e0 [ 57.590837] ? iptdotable+0x32e/0x430 [ 57.591221] ? brhandlelocalfinish+0x20/0x20 [ 57.591656] brnfhookthresh+0x4b/0xf0 [brnetfilter] [ 57.592286] ? brhandlelocalfinish+0x20/0x20 [ 57.592802] brnfpreroutingfinish+0x178/0x480 [brnetfilter] [ 57.593348] ? brhandlelocalfinish+0x20/0x20 [ 57.593782] ? nfnatipv4prerouting+0x25/0x60 [nfnat] [ 57.594279] brnfprerouting+0x24c/0x550 [brnetfilter] [ 57.594780] ? brnfhookthresh+0xf0/0xf0 [brnetfilter] [ 57.595280] brhandleframe+0x1f3/0x3d0 [ 57.595676] ? brhandlelocalfinish+0x20/0x20 [ 57.596118] ? brhandleframefinish+0x5e0/0x5e0 [ 57.596566] netifreceiveskbcore+0x25b/0xfc0 [ 57.597017] ? napibuildskb+0x37/0x40 [ 57.597418] netifreceiveskblistcore+0xfb/0x220
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smb2allocaterspbuf
If ->ProtocolId is SMB2TRANSFORMPROTONUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2queryinforeq), slab-out-of-bounds read can happen in smb2allocaterspbuf(). This patch allocate response buffer after decrypting transform request. smb3decryptreq() will validate transform request size and avoid slab-out-of-bound in smb2allocaterspbuf().
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix info leak when fetching fw build id
Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by scosocktimeout
The Linux kernel CVE team has assigned CVE-2024-27398 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051355-CVE-2024-27398-08ef@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
The Linux kernel CVE team has assigned CVE-2024-26922 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024042317-CVE-2024-26922-896d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
afunix: Fix garbage collector racing against connect()
Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCMRIGHTS, two consecutive passes of scanchildren() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gcinflightlist.
sockets are AFUNIX/SOCKSTREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped
connect(S, addr) sendmsg(S, [V]); close(V) unixgc() ---------------- ------------------------- -----------
NS = unixcreate1() skb1 = sockwmalloc(NS) L = unixfindother(addr) unixstatelock(L) unixpeer(S) = NS // V count=1 inflight=0
NS = unixpeer(S) skb2 = sockalloc() skbqueuetail(NS, skb2[V])
// V became in-flight // V count=2 inflight=1
close(V)
// V count=1 inflight=1 // GC candidate condition met
for u in gcinflightlist: if (totalrefs == inflightrefs) add u to gccandidates
// gccandidates={L, V}
for u in gccandidates: scanchildren(u, decinflight)
// embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged skbqueuetail(L, skb1) unixstateunlock(L) for u in gccandidates: if (u.inflight) scanchildren(u, incinflightmovetail)
// V count=1 inflight=2 (!)
If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCMRIGHTS. At this point, unixinflight() can not happen because unixgclock is already taken. Inflight graph remains unaffected.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsetpipapo: do not free live element
Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:
addelem("00000000") timeout 100 ms ... addelem("0000000X") timeout 100 ms delelem("0000000X") <---------------- delete one that was just added ... addelem("00005000") timeout 100 ms
1) nftpipaporemove() removes element 0000000X Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.
The remove function does not work correctly if we have more than one element that share the same key.
This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.
The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).
Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.
v2: avoid uneeded temporary variable (Stefano)
In the Linux kernel, the following vulnerability has been resolved:
binder: check offset alignment in bindergetobject()
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binderalloccopyfrombuffer() -> checkbuffer().
These calls were replaced in bindergetobject() with copyfromuser(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: fncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down, ethstop() is called. At this piont, accidentally if usb transport error should happen in usbepenable(), 'inep' and/or 'outep' may not be enabled.
After that, ncmdisable() is called to disable for ncm unbind but getherdisconnect() is never called since 'inep' is not enabled.
As the result, ncm object is released in ncm unbind but 'dev->portusb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and ethstartxmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs] usb0: ethstop dev->portusb=ffffff9b179c3200 --> error happens in usbepenable(). NCM: ncmdisable: ncm=ffffff9b179c3200 --> no getherdisconnect() since ncm->port.inep->enabled is false. NCM: ncmunbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncmfree: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs] NCM: ncmalloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncmbind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncmsetalt: ncm=ffffff9ac4f8a000 alt=0 usb0: ethopen dev->portusb=ffffff9b179c3200 <-- previous released ncm usb0: ethstart dev->portusb=ffffff9b179c3200 <-- ethstartxmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncmdisable() to call getherdisconnect() to deassociate 'dev->portusb'. It's more reasonable to check 'ncm->netdev' to call getherconnect/disconnect rather than check 'ncm->port.inep->enabled' since it might not be enabled but the gether connection might be established.
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access reqlist while it's being manipulated
The icclock mutex was split into separate icclock and iccbwlock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to iccnode::reqlist.
The iccsetbw() function will eventually iterate over reqlist while only holding iccbwlock, but reqlist can be modified while only holding icclock. This causes races between iccsetbw(), oficcget(), and iccput().
Example A:
CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); iccput(pathb) mutexlock(&icclock); aggregaterequests() hlistforeachentry(r, ... hlistdel(... <r = invalid pointer>
Example B:
CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); pathb = oficcget() oficcgetbyindex() mutexlock(&icclock); pathfind() pathinit() aggregaterequests() hlistforeachentry(r, ... hlistaddhead(... <r = invalid pointer>
Fix this by ensuring iccbwlock is always held before manipulating iccnode::reqlist. The additional places iccbwlock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: Correct the PDO counting in pdset
Off-by-one errors happen because nrsnkpdo and nrsrcpdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one.
When doing the power negotiation, TCPM relies on the "nrsnkpdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected).
"nrsrcpdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: restore set elements when delete set fails
From abort path, nftmapelemactivate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).
This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.
Toggle next generation bit for elements when delete set command is invoked and call nftclear() from .activate (abort) path to restore the next generation bit.
The splat below shows an object in mappings memleak:
[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nftables.h:1237 nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [...] [43929.458014] RIP: 0010:nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? warn+0x9f/0x1a0 [43929.458127] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458188] ? reportbug+0x1b1/0x1e0 [43929.458196] ? handlebug+0x3c/0x70 [43929.458200] ? excinvalidop+0x17/0x40 [43929.458211] ? nftsetelemdatadeactivate+0xd7/0xf0 [nftables] [43929.458271] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458332] nftmapelemdeactivate+0x24/0x30 [nftables] [43929.458392] nftrhashwalk+0xdd/0x180 [nftables] [43929.458453] ? pfxnftrhashwalk+0x10/0x10 [nftables] [43929.458512] ? rbinsertcolor+0x2e/0x280 [43929.458520] nftmapdeactivate+0xdc/0x1e0 [nftables] [43929.458582] ? pfxnftmapdeactivate+0x10/0x10 [nftables] [43929.458642] ? pfxnftmapelemdeactivate+0x10/0x10 [nftables] [43929.458701] ? rcureadunlock+0x46/0x70 [43929.458709] nftdelset+0xff/0x110 [nftables] [43929.458769] nftflushtable+0x16f/0x460 [nftables] [43929.458830] nftablesdeltable+0x501/0x580 [nftables]
In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.
bootconfig: use memblockfreelate to free xbc memory to buddy
In the Linux kernel, the following vulnerability has been resolved:
arm64: hibernate: Fix level3 translation fault in swsuspsave()
On arm64 machines, swsuspsave() faults if it attempts to access MEMBLOCKNOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debugpagealloc=off and CONFIGKFENCE=n:
Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xtmultiport iptREJECT nfrejectipv4 xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 libcrc32c iptablefilter bpfilter rfkill at803x sndhdacodechdmi sndhdaintel sndinteldspcfg dwmacgeneric stmmacplatform sndhdacodec stmmac joydev pcsxpcs sndhdacore phylink ppdev lp parport ramoops reedsolomon iptables xtables nlsiso88591 vfat multipath linear amdgpu amdxcp drmexec gpusched drmbuddy hidgeneric usbhid hid radeon video drmsuballochelper drmttmhelper ttm i2calgobit drmdisplayhelper cec drmkmshelper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsuspsave+0x280/0x538 lr : swsuspsave+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsuspsave+0x280/0x538 swsusparchsuspend+0x148/0x190 hibernationsnapshot+0x240/0x39c hibernate+0xc4/0x378 statestore+0xf0/0x10c kobjattrstore+0x14/0x24
The reason is swsuspsave() -> copydatapages() -> pageissaveable() -> kernelpagepresent() assuming that a page is always present when cansetdirectmap() is false (all of rodatafull, debugpageallocenabled() and arm64kfencecansetdirectmap() false), irrespective of the MEMBLOCKNOMAP ranges. Such MEMBLOCKNOMAP regions should not be saved during hibernation.
This problem was introduced by changes to the pfnvalid() logic in commit a7d9f306ba70 ("arm64: drop pfnvalidwithin() and simplify pfnvalid()").
Similar to other architectures, drop the !cansetdirectmap() check in kernelpagepresent() so that pageissavable() skips such pages.
[catalin.marinas@arm.com: rework commit message]
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: Fix potential data-race in nftexprtypeget()
nftunregisterexpr() can concurrent with nftexprtypeget(), and there is not any protection when iterate over nftablesexpressions list in nftexprtypeget(). Therefore, there is potential data-race of nftablesexpressions list entry.
Use listforeachentryrcu() to iterate over nftablesexpressions list in nftexprtypeget(), and use rcureadlock() in the caller nftexprtypeget() to protect the entire type query process.
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uarthandlectschange() function in serialcore expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serialcore.c:3453 uarthandlectschange+0xb4/0xec [ 85.134694] Modules linked in: hciuart bluetooth ecdhgeneric ecc wlcoresdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hcipoweron [bluetooth] (...) [ 85.191765] uarthandlectschange from mxsauartirqhandle+0x380/0x3f4 [ 85.198787] mxsauartirqhandle from handleirqeventpercpu+0x88/0x210 (...)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsetpipapo: walk over current view on netlink dump
The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.
Based on patch from Florian Westphal.