bpf: consider that tail calls invalidate packet pointers
bpf: check changespktdata property for extension programs
bpf: track changespktdata property for global functions
gfs2: Truncate address space when flipping GFS2DIFJDATA flag
In the Linux kernel, the following vulnerability has been resolved:
Revert "libfs: fix infinite directory reads for offset dir"
The current directory offset allocator (based on mtreealloccyclic) stores the next offset value to return in octx->nextoffset. This mechanism typically returns values that increase monotonically over time. Eventually, though, the newly allocated offset value wraps back to a low number (say, 2) which is smaller than other already- allocated offset values.
Yu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir"), if a directory's offset allocator wraps, existing entries are no longer visible via readdir/getdents because offsetreaddir() stops listing entries once an entry's offset is larger than octx->nextoffset. These entries vanish persistently -- they can be looked up, but will never again appear in readdir(3) output.
The reason for this is that the commit treats directory offsets as monotonically increasing integer values rather than opaque cookies, and introduces this comparison:
if (dentry2offset(dentry) >= lastindex) {
On 64-bit platforms, the directory offset value upper bound is 2^63 - 1. Directory offsets will monotonically increase for millions of years without wrapping.
On 32-bit platforms, however, LONGMAX is 2^31 - 1. The allocator can wrap after only a few weeks (at worst).
Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir") to prepare for a fix that can work properly on 32-bit systems and might apply to recent LTS kernels where shmem employs the simpleoffset mechanism.
drm/v3d: Ensure job pointer is set to NULL after job completion
hrtimers: Handle CPU state correctly on hotplug
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: properly synchronize freeing resources during CPU hotunplug
In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.
If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).
The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.
Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.
Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].
Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
[1]
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix ets qdisc OOB Indexing
Haowei Yan <g1042620637@gmail.com> found that etsclassfromarg() can index an Out-Of-Bound class in etsclassfromarg() when passed clid of 0. The overflow may cause local privilege escalation.
[ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/schets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'etsclass [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dumpstacklvl+0xc2/0xf0 [ 18.859607] dumpstack+0x10/0x20 [ 18.860908] ubsanhandleoutofbounds+0xa7/0xf0 [ 18.864022] etsclasschange+0x3d6/0x3f0 [ 18.864322] tcctltclass+0x251/0x910 [ 18.864587] ? lockacquire+0x5e/0x140 [ 18.865113] ? mutexlock+0x9c/0xe70 [ 18.866009] ? mutexlock+0xa34/0xe70 [ 18.866401] rtnetlinkrcvmsg+0x170/0x6f0 [ 18.866806] ? lockacquire+0x578/0xc10 [ 18.867184] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 18.867503] netlinkrcvskb+0x59/0x110 [ 18.867776] rtnetlinkrcv+0x15/0x30 [ 18.868159] netlinkunicast+0x1c3/0x2b0 [ 18.868440] netlinksendmsg+0x239/0x4b0 [ 18.868721] syssendmsg+0x3e2/0x410 [ 18.869012] syssendmsg+0x88/0xe0 [ 18.869276] ? rseqipfixup+0x198/0x260 [ 18.869563] ? rsequpdatecpunodeid+0x10a/0x190 [ 18.869900] ? tracehardirqsoff+0x5a/0xd0 [ 18.870196] ? syscallexittousermode+0xcc/0x220 [ 18.870547] ? dosyscall64+0x93/0x150 [ 18.870821] ? memcgslabfreehook+0x69/0x290 [ 18.871157] syssendmsg+0x69/0xd0 [ 18.871416] x64syssendmsg+0x1d/0x30 [ 18.871699] x64syscall+0x9e2/0x2670 [ 18.871979] dosyscall64+0x87/0x150 [ 18.873280] ? dosyscall64+0x93/0x150 [ 18.874742] ? lockrelease+0x7b/0x160 [ 18.876157] ? douseraddrfault+0x5ce/0x8f0 [ 18.877833] ? irqentryexittousermode+0xc2/0x210 [ 18.879608] ? irqentryexit+0x77/0xb0 [ 18.879808] ? clearbhbloop+0x15/0x70 [ 18.880023] ? clearbhbloop+0x15/0x70 [ 18.880223] ? clearbhbloop+0x15/0x70 [ 18.880426] entrySYSCALL64afterhwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIGRAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]---
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.
eth: bnxt: always recalculate features after XDP clearing, fix null-deref
In the Linux kernel, the following vulnerability has been resolved:
pktgen: Avoid out-of-bounds access in getimixentries
Passing a sufficient amount of imix entries leads to invalid access to the pktdev->imixentries array because of the incorrect boundary check.
UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imixpkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl lib/dumpstack.c:117 ubsanhandleoutofbounds lib/ubsan.c:429 getimixentries net/core/pktgen.c:874 pktgenifwrite net/core/pktgen.c:1063 pdewrite fs/proc/inode.c:334 procregwrite fs/proc/inode.c:346 vfswrite fs/readwrite.c:593 ksyswrite fs/readwrite.c:644 dosyscall64 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe arch/x86/entry/entry64.S:130
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[ fp: allow to fill the array completely; minor changelog cleanup ]
In the Linux kernel, the following vulnerability has been resolved:
gtp: Destroy device along with udp socket's netns dismantle.
gtpnewlink() links the device to a list in devnet(dev) instead of srcnet, where a udp tunnel socket is created.
Even when srcnet is removed, the device stays alive on devnet(dev). Then, removing srcnet triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtpnetexitbatchrtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: reftracker: net notrefcnt@000000003d6e7d05 has 1/2 users at skalloc (./include/net/netnamespace.h:345 net/core/sock.c:2236) inetcreate (net/ipv4/afinet.c:326 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1558) udpsockcreate4 (net/ipv4/udptunnelcore.c:18) gtpcreatesock (./include/net/udptunnel.h:59 drivers/net/gtp.c:1423) gtpcreatesockets (drivers/net/gtp.c:1447) gtpnewlink (drivers/net/gtp.c:1507) rtnlnewlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlinkrcvmsg (net/core/rtnetlink.c:6922) netlinkrcvskb (net/netlink/afnetlink.c:2542) netlinkunicast (net/netlink/afnetlink.c:1321 net/netlink/afnetlink.c:1347) netlinksendmsg (net/netlink/afnetlink.c:1891) syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) syssendmsg (net/socket.c:2639) syssendmsg (net/socket.c:2669) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:reftrackerdirexit (lib/reftracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn (kernel/panic.c:748) ? reftrackerdirexit (lib/reftracker.c:179) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:285) ? excinvalidop (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? rawspinunlockirqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlockapismp.h:151 kernel/locking/spinlock.c:194) ? reftrackerdirexit (lib/reftracker.c:179) ? pfxreftrackerdirexit (lib/reftracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) netfree (net/core/netnamespace.c:476 net/core/netnamespace.c:467) cleanupnet (net/core/netnamespace.c:664 (discriminator 3)) processonework (kernel/workqueue.c:3229) workerthread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
pfcp: Destroy device along with udp socket's netns dismantle.
pfcpnewlink() links the device to a list in devnet(dev) instead of net, where a udp tunnel socket is created.
Even when net is removed, the device stays alive on devnet(dev). Then, removing net triggers the splat below. [0]
In this example, pfcp0 is created in ns2, but the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name pfcp0 type pfcp ip netns del ns1
Let's link the device to the socket's netns instead.
Now, pfcpnetexit() needs another netdev iteration to remove all pfcp devices in the netns.
pfcpdevlist is not used under RCU, so the list API is converted to the non-RCU variant.
pfcpnetexit() can be converted to .exitbatchrtnl() in net-next.
[0]: reftracker: net notrefcnt@00000000128b34dc has 1/1 users at skalloc (./include/net/netnamespace.h:345 net/core/sock.c:2236) inetcreate (net/ipv4/afinet.c:326 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1558) udpsockcreate4 (net/ipv4/udptunnelcore.c:18) pfcpcreatesock (drivers/net/pfcp.c:168) pfcpnewlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197) rtnlnewlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlinkrcvmsg (net/core/rtnetlink.c:6922) netlinkrcvskb (net/netlink/afnetlink.c:2542) netlinkunicast (net/netlink/afnetlink.c:1321 net/netlink/afnetlink.c:1347) netlinksendmsg (net/netlink/afnetlink.c:1891) syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) syssendmsg (net/socket.c:2639) syssendmsg (net/socket.c:2669) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)
WARNING: CPU: 1 PID: 11 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:reftrackerdirexit (lib/reftracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000007f3fb60 EFLAGS: 00010286 RAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af R10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230 R13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn (kernel/panic.c:748) ? reftrackerdirexit (lib/reftracker.c:179) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:285) ? excinvalidop (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? rawspinunlockirqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlockapismp.h:151 kernel/locking/spinlock.c:194) ? reftrackerdirexit (lib/reftracker.c:179) ? pfxreftrackerdirexit (lib/reftracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) netfree (net/core/netnamespace.c:476 net/core/netnamespace.c:467) cleanupnet (net/cor ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: fec: handle pagepooldevallocpages error
The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.
This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.
Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.
This commit handles the allocation error by dropping the current packet.
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: discard packets if the transport changes
If the socket has been de-assigned or assigned to another transport, we must discard any packets received because they are not expected and would cause issues when we access vsk->transport.
A possible scenario is described by Hyunwoo Kim in the attached link, where after a first connect() interrupted by a signal, and a second connect() failed, we can find vsk->transport at NULL, leading to a NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved:
dm thin: make getfirstthin use rcu-safe list first function
The documentation in rculist.h explains the absence of listemptyrcu() and cautions programmers against relying on a listempty() -> listfirst() sequence in RCU safe code. This is because each of these functions performs its own READONCE() of the list head. This can lead to a situation where the listempty() sees a valid list entry, but the subsequent listfirst() sees a different view of list head state after a modification.
In the case of dm-thin, this author had a production box crash from a GP fault in the processdeferredbios path. This function saw a valid list head in getfirstthin() but when it subsequently dereferenced that and turned it into a thinc, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcountt being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thindtr's synchronizercu.
The thindtr call managed to pull the thinc out of the active thins list (and have it be the last entry in the activethins list) at just the wrong moment which lead to this crash.
Fortunately, the fix here is straight forward. Switch getfirstthin() function to use listfirstornullrcu() which performs just a single READONCE() and returns NULL if the list is already empty.
This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed.
In the Linux kernel, the following vulnerability has been resolved:
gpio: virtuser: fix missing lookup table cleanups
When a virtuser device is created via configfs and the probe fails due to an incorrect lookup table, the table is not removed. This prevents subsequent probe attempts from succeeding, even if the issue is corrected, unless the device is released. Additionally, cleanup is also needed in the less likely case of platformdeviceregisterfull() failure.
Besides, a consistent memory leak in lookuptable->devid was spotted using kmemleak by toggling the live state between 0 and 1 with a correct lookup table.
Introduce gpiovirtuserremovelookuptable() as the counterpart to the existing gpiovirtusermakelookuptable() and call it from all necessary points to ensure proper cleanup.
In the Linux kernel, the following vulnerability has been resolved:
netdev: prevent accessing NAPI instances from another namespace
The NAPI IDs were not fully exposed to user space prior to the netlink API, so they were never namespaced. The netlink API must ensure that at the very least NAPI instance belongs to the same netns as the owner of the genl sock.
napibyid() can become static now, but it needs to move because of devgetbynapiid().
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page )VMEMMAPSTART - (physrambase >> PAGESHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the first page from the same section that physrambase belongs to. If the first page's physical address is not (physrambase >> PAGESHIFT), then we get an va below VMEMMAPSTART when calculating va for it's struct page.
For example, if physrambase starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During initunavailablerange(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page )VMEMMAPSTART - 0x2000), which is below VMEMMAPSTART as well as PCIIOEND.
This commit fixes this bug by introducing a new variable 'vmemmapstartpfn' which is aligned with memory section size and using it to calculate vmemmap address instead of physrambase.
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix the new buffer was not zeroed before writing
Before writing, if a bufferhead marked as new, its data must be zeroed, otherwise uninitialized data in the page cache will be written.
So this commit uses foliozeronewbuffers() to zero the new buffers before ->writeend().
In the Linux kernel, the following vulnerability has been resolved:
iouring/eventfd: ensure ioeventfdsignal() defers another RCU period
ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.
Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.
In the Linux kernel, the following vulnerability has been resolved:
dm array: fix releasing a faulty array block twice in dmarraycursorend
When dmbmreadlock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dmbmreadlock() should not operate on this invalid dmblock pointer, or it will lead to undefined result. For example, the dmarraycursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double release in dmarraycursorend(), then hitting the BUGON in dm-bufio cacheput().
Reproduce steps:
1. initialize a cache device
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
2. wipe the second array block offline
dmsteup remove cache cmeta cdata corig mappingroot=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096mappingroot+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
3. try reopen the cache device
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
Kernel logs:
(snip) device-mapper: array: arrayblockcheck failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: getablock failed device-mapper: cache metadata: dmarraycursornext for mapping failed ------------[ cut here ]------------ kernel BUG at drivers/md/dm-bufio.c:638!
Fix by setting the cached block pointer to NULL on errors.
In addition to the reproducer described above, this fix can be verified using the "arraycursor/damaged" test in dm-unit: dm-unit run /pdata/arraycursor/damaged --kernel-dir <KERNELDIR>
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix enomem handling in buffered reads
If netfsreadtopagecache() gets an error from either ->prepareread() or from netfspreparereaditerator(), it needs to decrement ->nroutstanding, cancel the subrequest and break out of the issuing loop. Currently, it only does this for two of the cases, but there are two more that aren't handled.
Fix this by moving the handling to a common place and jumping to it from all four places. This is in preference to inserting a wrapper around netfspreparereaditerator() as proposed by Dmitry Antipov[1].
drm/mediatek: Set private->alldrmprivate[i]->drm to NULL if mtkdrmbind returns err
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix a missing return value check bug
In the smb2sendinterimresp(), if ksmbdallocworkstruct() fails to allocate a node, it returns a NULL pointer to the inwork pointer. This can lead to an illegal memory write of inwork->responsebuf when allocateinterimrspbuf() attempts to perform a kzalloc() on it.
To address this issue, incorporating a check for the return value of ksmbdallocworkstruct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Add a lock when accessing the buddy trim function
When running YouTube videos and Steam games simultaneously, the tester found a system hang / race condition issue with the multi-display configuration setting. Adding a lock to the buddy allocator's trim function would be the solution.
<log snip> [ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108 [ 7197.250447] RIP: 0010:allocrange+0x8b/0x340 [amddrmbuddy] [ 7197.250470] Call Trace: [ 7197.250472] <TASK> [ 7197.250475] ? showregs+0x6d/0x80 [ 7197.250481] ? dieaddr+0x37/0xa0 [ 7197.250483] ? excgeneralprotection+0x1db/0x480 [ 7197.250488] ? drmsuballocnew+0x13c/0x93d [drmsuballochelper] [ 7197.250493] ? asmexcgeneralprotection+0x27/0x30 [ 7197.250498] ? allocrange+0x8b/0x340 [amddrmbuddy] [ 7197.250501] ? allocrange+0x109/0x340 [amddrmbuddy] [ 7197.250506] amddrmbuddyblocktrim+0x1b5/0x260 [amddrmbuddy] [ 7197.250511] amdgpuvrammgrnew+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttmresourcealloc+0x46/0xb0 [amdttm] [ 7197.250689] ttmboallocresource+0xe4/0x370 [amdttm] [ 7197.250696] amdttmbovalidate+0x9d/0x180 [amdttm] [ 7197.250701] amdgpubopin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpudmplanehelperpreparefb+0xb2/0x360 [amdgpu] [ 7197.251025] ? trywaitforcompletion+0x59/0x70 [ 7197.251030] drmatomichelperprepareplanes.part.0+0x2f/0x1e0 [ 7197.251035] drmatomichelperprepareplanes+0x5d/0x70 [ 7197.251037] drmatomichelpercommit+0x84/0x160 [ 7197.251040] drmatomicnonblockingcommit+0x59/0x70 [ 7197.251043] drmmodeatomicioctl+0x720/0x850 [ 7197.251047] ? pfxdrmmodeatomicioctl+0x10/0x10 [ 7197.251049] drmioctlkernel+0xb9/0x120 [ 7197.251053] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 7197.251056] drmioctl+0x2d4/0x550 [ 7197.251058] ? pfxdrmmodeatomicioctl+0x10/0x10 [ 7197.251063] amdgpudrmioctl+0x4e/0x90 [amdgpu] [ 7197.251186] x64sysioctl+0xa0/0xf0 [ 7197.251190] x64syscall+0x143b/0x25c0 [ 7197.251193] dosyscall64+0x7f/0x180 [ 7197.251197] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 7197.251199] ? amdgpudisplayuserframebuffercreate+0x215/0x320 [amdgpu] [ 7197.251329] ? drminternalframebuffercreate+0xb7/0x1a0 [ 7197.251332] ? srsoaliasreturnthunk+0x5/0xfbef5
(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix page fault due to max surface definition mismatch
DC driver is using two different values to define the maximum number of surfaces: MAXSURFACES and MAXSURFACENUM. Consolidate MAXSURFACES as the unique definition for surface updates across DC.
It fixes page fault faced by Cosmic users on AMD display versions that support two overlay planes, since the introduction of cursor overlay mode.
[Nov26 21:33] BUG: unable to handle page fault for address: 0000000051d0f08b [ +0.000015] #PF: supervisor read access in kernel mode [ +0.000006] #PF: errorcode(0x0000) - not-present page [ +0.000005] PGD 0 P4D 0 [ +0.000007] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000006] CPU: 4 PID: 71 Comm: kworker/u32:6 Not tainted 6.10.0+ #300 [ +0.000006] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ +0.000007] Workqueue: eventsunbound commitwork [drmkmshelper] [ +0.000040] RIP: 0010:copystreamupdatetostream.isra.0+0x30d/0x750 [amdgpu] [ +0.000847] Code: 8b 10 49 89 94 24 f8 00 00 00 48 8b 50 08 49 89 94 24 00 01 00 00 8b 40 10 41 89 84 24 08 01 00 00 49 8b 45 78 48 85 c0 74 0b <0f> b6 00 41 88 84 24 90 64 00 00 49 8b 45 60 48 85 c0 74 3b 48 8b [ +0.000010] RSP: 0018:ffffc203802f79a0 EFLAGS: 00010206 [ +0.000009] RAX: 0000000051d0f08b RBX: 0000000000000004 RCX: ffff9f964f0a8070 [ +0.000004] RDX: ffff9f9710f90e40 RSI: ffff9f96600c8000 RDI: ffff9f964f000000 [ +0.000004] RBP: ffffc203802f79f8 R08: 0000000000000000 R09: 0000000000000000 [ +0.000005] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9f96600c8000 [ +0.000004] R13: ffff9f9710f90e40 R14: ffff9f964f000000 R15: ffff9f96600c8000 [ +0.000004] FS: 0000000000000000(0000) GS:ffff9f9970000000(0000) knlGS:0000000000000000 [ +0.000005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000005] CR2: 0000000051d0f08b CR3: 00000002e6a20000 CR4: 0000000000350ef0 [ +0.000005] Call Trace: [ +0.000011] <TASK> [ +0.000010] ? diebody.cold+0x19/0x27 [ +0.000012] ? pagefaultoops+0x15a/0x2d0 [ +0.000014] ? excpagefault+0x7e/0x180 [ +0.000009] ? asmexcpagefault+0x26/0x30 [ +0.000013] ? copystreamupdatetostream.isra.0+0x30d/0x750 [amdgpu] [ +0.000739] ? dccommitstatenocheck+0xd6c/0xe70 [amdgpu] [ +0.000470] updateplanesandstreamstate+0x49b/0x4f0 [amdgpu] [ +0.000450] ? srsoreturnthunk+0x5/0x5f [ +0.000009] ? commitminimaltransitionstate+0x239/0x3d0 [amdgpu] [ +0.000446] updateplanesandstreamv2+0x24a/0x590 [amdgpu] [ +0.000464] ? srsoreturnthunk+0x5/0x5f [ +0.000009] ? sort+0x31/0x50 [ +0.000007] ? amdgpudmatomiccommittail+0x159f/0x3a30 [amdgpu] [ +0.000508] ? srsoreturnthunk+0x5/0x5f [ +0.000009] ? amdgpucrtcgetscanoutposition+0x28/0x40 [amdgpu] [ +0.000377] ? srsoreturnthunk+0x5/0x5f [ +0.000009] ? drmcrtcvblankhelpergetvblanktimestampinternal+0x160/0x390 [drm] [ +0.000058] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? dmafencedefaultwait+0x8c/0x260 [ +0.000010] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? waitforcompletiontimeout+0x13b/0x170 [ +0.000006] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? dmafencewaittimeout+0x108/0x140 [ +0.000010] ? committail+0x94/0x130 [drmkmshelper] [ +0.000024] ? processonework+0x177/0x330 [ +0.000008] ? workerthread+0x266/0x3a0 [ +0.000006] ? pfxworkerthread+0x10/0x10 [ +0.000004] ? kthread+0xd2/0x100 [ +0.000006] ? pfxkthread+0x10/0x10 [ +0.000006] ? retfromfork+0x34/0x50 [ +0.000004] ? pfxkthread+0x10/0x10 [ +0.000005] ? retfromforkasm+0x1a/0x30 [ +0.000011] </TASK>
(cherry picked from commit 1c86c81a86c60f9b15d3e3f43af0363cf56063e7)
In the Linux kernel, the following vulnerability has been resolved:
topology: Keep the cpumask unchanged when printing cpumap
During fuzz testing, the following warning was discovered:
different return values (15 and 11) from vsnprintf("%pbl ", ...)
test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2
The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:
(1) First, calculate the length of the resulting formatted string.
(2) Allocate a buffer based on the returned length.
(3) Then, perform the actual string formatting.
(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.
If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.
To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.
iio: pressure: zpa2326: fix information leak in triggered buffer