crypto: starfive - Do not free stack buffer
Bluetooth: HCI: Remove HCIAMP support
afunix: Set gcinprogress to true in unixgc().
In the Linux kernel, the following vulnerability has been resolved:
cppccpufreq: Fix possible null pointer dereference
cppccpufreqgetrate() and hisicppccpufreqgetrate() can be called from different places with various parameters. So cpufreqcpuget() can return null as 'policy' in some circumstances. Fix this bug by adding null return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix null pointer dereference in compareguidkey()
sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.
If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.
Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:
general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...
Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.
Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.
In the Linux kernel, the following vulnerability has been resolved:
fuse: clear intrentry in fuseresend and fuseremovependingreq
When fuseresend() moves a request from fpq->processing back to fiq->pending, it sets FRPENDING and clears FRSENT but does not remove the requests intrentry from fiq->interrupts. If the request had FRINTERRUPTED set from a prior signal, intrentry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuseremovependingreq() sees FRPENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intrentry. The stale intrentry causes use-after-free when fusereadinterrupt() iterates fiq->interrupts: - listdelinit(&req->intrentry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace
Remove intrentry from fiq->interrupts in fuseresend() for interrupted requests before they are placed back on fiq->pending.
Add a WARNON if the intrentry is not empty on request destruction.
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads1298: add bounds check to pgasettings index
ads1298pgasettings has 7 elements but ADS1298MASKCHPGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range.
Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system.
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:
wifi: mac80211: consume only present negotiated TTLM maps
ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.
The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.
The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.
Advance the cursor only when the current TID has a map present.
In the Linux kernel, the following vulnerability has been resolved:
timers/migration: Fix livelock in tmigrhandleremoteup()
tmigrhandleremotecpu() skips timerexpireremote() when cpu == smpprocessorid(), assuming the local softirq path already handled this CPU's timers.
This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in runtimerbase(BASEGLOBAL) and before tmigrhandleremote() evaluates the expiry times.
As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel.
What's worse is that fetchnexttimerinterruptremote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely.
Fix this by calling timerexpireremote() unconditionally. That's minimal overhead for the common case as runtimerbase() returns immediately if there is nothing to expire in the local wheel.
[ tglx: Amend change log and add a comment ]
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:
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:
drm/amd/display: Fix out-of-bounds stream encoder index v3
engid can be negative and that streamencregs[] can be indexed out of bounds.
engid is used directly as an index into streamencregs[], which has only 5 entries. When engid is 5 (ENGINEIDDIGF) or negative, this can access memory past the end of the array.
Add a bounds check using ARRAYSIZE() before using engid as an index. The unsigned cast also rejects negative values.
This avoids out-of-bounds access.
Fixes the below smatch error: dcnresource.c: streamencodercreate() may index streamencregs[engid] out of bounds (size 5).
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351resource.c 1246 static struct streamencoder dcn35streamencodercreate( 1247 enum engineid engid, 1248 struct dccontext ctx) 1249 {
...
1255 1256 / Mapping of VPG, AFMT, DME register blocks to DIO block instance / 1257 if (engid <= ENGINEIDDIGF) {
ENGINEIDDIGF is 5. should <= be <?
Unrelated but, ugh, why is Smatch saying that "engid" can be negative? endid is type signed long, but there are checks in the caller which prevent it from being negative.
1258 vpginst = engid; 1259 afmtinst = engid; 1260 } else 1261 return NULL; 1262
...
1281 1282 dcn35diostreamencoderconstruct(enc1, ctx, ctx->dcbios, 1283 engid, vpg, afmt, --> 1284 &streamencregs[engid], ^^^^^^^^^^^^^^^^^^^^^^^ This streamencregs[] array has 5 elements so we are one element beyond the end of the array.
...
1287 return &enc1->base; 1288 }
v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast
v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: take vmappurgelock in shrinker
decayvapoolnode() can be invoked concurrently from two paths: purgevmaparealazy() when pools are being purged, and the shrinker via vmapnodeshrinkscan().
However, decayvapoolnode() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks.
Protect decayvapoolnode() by taking vmappurgelock in the shrinker path to ensure serialization with purge users.
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:
net: nexthop: fix percpu use-after-free in removenhgrpentry
When removing a nexthop from a group, removenhgrpentry() publishes the new group via rcuassignpointer() then immediately frees the removed entry's percpu stats with freepercpu(). However, the synchronizenet() grace period in the caller removenexthopfromgroups() runs after the free. RCU readers that entered before the publish still see the old group and can dereference the freed stats via nhgrpentrystatsinc() -> getcpuptr(nhge->stats), causing a use-after-free on percpu memory.
Fix by deferring the freepercpu() until after synchronizenet() in the caller. Removed entries are chained via nhlist onto a local deferred free list. After the grace period completes and all RCU readers have finished, the percpu stats are safely freed.
In the Linux kernel, the following vulnerability has been resolved:
nvmem: zynqmpnvmem: Fix buffer size in DMA and memcpy
Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dmaalloccoherent and memcpy.
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:
net: octeonepvf: fix freeirq devid mismatch in IRQ rollback
octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.
This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.
Fix the error path to free IRQs with the same ioqvector devid used during requestirq().
In the Linux kernel, the following vulnerability has been resolved:
Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"
This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime.
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:
smb/server: fix refcount leak in parsedurablehandlecontext()
When the command is a replay operation and -ENOEXEC is returned, the refcount of ksmbdfile must be released.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()
TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'
In the Linux kernel, the following vulnerability has been resolved:
igc: don't fail igcprobe() on LED setup error
When igcledsetup() fails, igcprobe() fails and triggers kernel panic in freenetdev() since unregisternetdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2]
Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic.
[1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:freenetdev+0x278/0x2b0 [...] Call Trace: <TASK> igcprobe+0x370/0x910 localpciprobe+0x3a/0x80 pcideviceprobe+0xd1/0x200 [...]
[2] #!/bin/bash -ex
FAILSLABPATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 STARTADDR=$(grep " igcledsetup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') ENDADDR=$(printf "0x%x" $((STARTADDR + 0x100)))
echo $STARTADDR > $FAILSLABPATH/require-start echo $ENDADDR > $FAILSLABPATH/require-end echo 1 > $FAILSLABPATH/times echo 100 > $FAILSLABPATH/probability echo N > $FAILSLABPATH/ignore-gfp-wait
echo $DEVICE > /sys/bus/pci/drivers/igc/bind
f2fs: zone: fix to avoid inconsistence in between SIT and SSA
In the Linux kernel, the following vulnerability has been resolved:
iouring: fix use-after-free of sq->thread in iouringshowfdinfo()
syzbot reports:
BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60 Read of size 8 at addr ffff88810de2d2c8 by task a.out/304
CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xd0/0x670 ? pfxrawspinlockirqsave+0x10/0x10 ? getrusage+0x1109/0x1a60 kasanreport+0xce/0x100 ? getrusage+0x1109/0x1a60 getrusage+0x1109/0x1a60 ? pfxgetrusage+0x10/0x10 iouringshowfdinfo+0x9fe/0x1790 ? ksysread+0xf7/0x1c0 ? dosyscall64+0xa4/0x260 ? vsnprintf+0x591/0x1100 ? pfxiouringshowfdinfo+0x10/0x10 ? pfxvsnprintf+0x10/0x10 ? mutextrylock+0xcf/0x130 ? pfxmutextrylock+0x10/0x10 ? pfxshowfdlocks+0x10/0x10 ? iouringshowfdinfo+0x57/0x80 iouringshowfdinfo+0x57/0x80 seqshow+0x38c/0x690 seqreaditer+0x3f7/0x1180 ? inodesetctimecurrent+0x160/0x4b0 seqread+0x271/0x3e0 ? pfxseqread+0x10/0x10 ? pfxrawspinlock+0x10/0x10 ? markinodedirty+0x402/0x810 ? selinuxfilepermission+0x368/0x500 ? fileupdatetime+0x10f/0x160 vfsread+0x177/0xa40 ? pfxhandlemmfault+0x10/0x10 ? pfxvfsread+0x10/0x10 ? mutexlock+0x81/0xe0 ? pfxmutexlock+0x10/0x10 ? fdgetpos+0x24d/0x4b0 ksysread+0xf7/0x1c0 ? pfxksysread+0x10/0x10 ? douseraddrfault+0x43b/0x9c0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f0f74170fc9 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 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 8b 8 RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9 RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004 RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90 R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>
Allocated by task 298: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasanslaballoc+0x6e/0x70 kmemcacheallocnodenoprof+0xe8/0x330 copyprocess+0x376/0x5e00 createiothread+0xab/0xf0 iosqoffloadcreate+0x9ed/0xf20 iouringsetup+0x12b0/0x1cc0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 22: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x37/0x50 kmemcachefree+0xc4/0x360 rcucore+0x5ff/0x19f0 handlesoftirqs+0x18c/0x530 runksoftirqd+0x20/0x30 smpbootthreadfn+0x287/0x6c0 kthread+0x30d/0x630 retfromfork+0xef/0x1a0 retfromforkasm+0x1a/0x30
Last potentially related work creation: kasansavestack+0x33/0x60 kasanrecordauxstack+0x8c/0xa0 callrcucommon.constprop.0+0x68/0x940 schedule+0xff2/0x2930 condresched+0x4c/0x80 mutexlock+0x5c/0xe0 iouringdeltctxnode+0xe1/0x2b0 iouringcleantctx+0xb7/0x160 iouringcancelgeneric+0x34e/0x760 doexit+0x240/0x2350 dogroupexit+0xab/0x220 x64sysexitgroup+0x39/0x40 x64syscall+0x1243/0x1840 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f
The buggy address belongs to the object at ffff88810de2cb00 which belongs to the cache taskstruct of size 3712 The buggy address is located 1992 bytes inside of freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980)
which is caused by the taskstruct pointed to by sq->thread being released while it is being used in the function iouringshowfdinfo(). Holding ctx->uringlock does not prevent ehre relase or exit of sq->thread.
Fix this by assigning and looking up ->thread under RCU, and grabbing a reference to the taskstruct. This e ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix array bounds error with maygoto
maygoto uses an additional 8 bytes on the stack, which causes the interpreters[] array to go out of bounds when calculating index by stacksize.
1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT cases, reject loading directly.
2. For non-JIT cases, calculating interpreters[idx] may still cause out-of-bounds array access, and just warn about it.
3. For jitrequested cases, the execution of bpffunc also needs to be warned. So move the definition of function bpfprogret0warn out of the macro definition CONFIGBPFJITALWAYSON.
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: clean up ROC on failure
If the firmware fails to start the session protection, then we do call iwlmvmrocfinished() here, but that won't do anything at all because IWLMVMSTATUSROCP2PRUNNING was never set. Set IWLMVMSTATUSROCP2PRUNNING in the failure/stop path. If it started successfully before, it's already set, so that doesn't matter, and if it didn't start it needs to be set to clean up.
Not doing so will lead to a WARNON() later on a fresh remain- on-channel, since the link is already active when activated as it was never deactivated.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix softlockup in arenamapfree on 64k page kernel
On an aarch64 kernel with CONFIGPAGESIZE64KB=y, arenahtab tests cause a segmentation fault and soft lockup. The same failure is not observed with 4k pages on aarch64.
It turns out arenamapfree() is calling applytoexistingpagerange() with the address returned by bpfarenagetkernvmstart(). If this address is not page-aligned the code ends up calling applytopterange() with that unaligned address causing soft lockup.
Fix it by round up GUARDSZ to PAGESIZE 1 so that the division by 2 in bpfarenagetkernvmstart() returns a page-aligned value.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject structops registration that uses module ptr and the module btfid is missing
There is a UAF report in the bpfstructops when CONFIGMODULES=n. In particular, the report is on tcpcongestionops that has a "struct module owner" member.
For structops that has a "struct module owner" member, it can be extended either by the regular kernel module or by the bpfstructops. bpftrymoduleget() will be used to do the refcounting and different refcount is done based on the owner pointer. When CONFIGMODULES=n, the btfid of the "struct module" is missing:
WARN: resolvebtfids: unresolved symbol module
Thus, the bpftrymoduleget() cannot do the correct refcounting.
Not all subsystem's structops requires the "struct module owner" member. e.g. the recent schedextops.
This patch is to disable bpfstructops registration if the structops has the "struct module " member and the "struct module" btfid is missing. The btftypeisfwd() helper is moved to the btf.h header file for this test.
This has happened since the beginning of bpfstructops which has gone through many changes. The Fixes tag is set to a recent commit that this patch can apply cleanly. Considering CONFIGMODULES=n is not common and the age of the issue, targeting for bpf-next also.