drm/amdgpu: Refactor amdgpugemvaioctl for Handling Last Fence Update and Timeline Management v4

In the Linux kernel, the following vulnerability has been resolved:

ublk: fix NULL pointer dereference in ublkctrlsetsize()

ublkctrlsetsize() unconditionally dereferences ub->ubdisk via setcapacityandnotify() without checking if it is NULL.

ub->ubdisk is NULL before UBLKCMDSTARTDEV completes (it is only assigned in ublkctrlstartdev()) and after UBLKCMDSTOPDEV runs (ublkdetachdisk() sets it to NULL). Since the UBLKCMDUPDATESIZE handler performs no state validation, a user can trigger a NULL pointer dereference by sending UPDATESIZE to a device that has been added but not yet started, or one that has been stopped.

Fix this by checking ub->ubdisk under ub->mutex before dereferencing it, and returning -ENODEV if the disk is not available.

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: fix RESPONSE authenticator parser OOB read

rxgkverifyauthenticator() copies authlen bytes into a temporary buffer and then passes p + authlen as the parser limit to rxgkdoverifyauthenticator(). Since p is a be32 , that inflates the parser end pointer by a factor of four and lets malformed RESPONSE authenticators read past the kmalloc() buffer.

Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:

BUG: KASAN: slab-out-of-bounds in rxgkverifyresponse() Call Trace: dumpstacklvl() [lib/dumpstack.c:123] printreport() [mm/kasan/report.c:379 mm/kasan/report.c:482] kasanreport() [mm/kasan/report.c:597] rxgkverifyresponse() [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]

Allocated by task 54: rxgkverifyresponse() [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386]

Convert the byte count to be32 units before constructing the parser limit.

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix integer overflow in rxgkverifyresponse()

In rxgkverifyresponse(), there's a potential integer overflow due to rounding up tokenlen before checking it, thereby allowing the length check to be bypassed.

Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet).

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: fix oversized RESPONSE authenticator length check

rxgkverifyresponse() decodes authlen from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgkdecryptskb(), which can later reach skbtosgvec() with an impossible length and hit BUGON(len).

Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:

RIP: skbtosgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skbtosgvec() [net/core/skbuff.c:5305] rxgkdecryptskb() [net/rxrpc/rxgkcommon.h:81] rxgkverifyresponse() [net/rxrpc/rxgk.c:1268] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]

Reject authenticator lengths that exceed the remaining packet payload.

In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix tracemarker copy link list updates

When the "copytracemarker" option is enabled for an instance, anything written into /sys/kernel/tracing/tracemarker is also copied into that instances buffer. When the option is set, that instance's tracearray descriptor is added to the markercopies link list. This list is protected by RCU, as all iterations uses an RCU protected list traversal.

When the instance is deleted, all the flags that were enabled are cleared. This also clears the copytracemarker flag and removes the tracearray descriptor from the list.

The issue is after the flags are called, a direct call to updatemarkertrace() is performed to clear the flag. This function returns true if the state of the flag changed and false otherwise. If it returns true here, synchronizercu() is called to make sure all readers see that its removed from the list.

But since the flag was already cleared, the state does not change and the synchronization is never called, leaving a possible UAF bug.

Move the clearing of all flags below the updating of the copytracemarker option which then makes sure the synchronization is performed.

Also use the flag for checking the state in updatemarkertrace() instead of looking at if the list is empty.

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: file: Use kzallocflex for aiocmd

The targetcorefile doesn't initialize the aiocmd->iocb for the kiwritestream. When a write command fdexecuterwaio() is executed, we may get a bogus kiwritestream value, causing unintended write failure status when checking iocb->kiwritestream > maxwritestreams in the block device.

Let's just use kzallocflex when allocating the aiocmd and let kiwritestream=0 to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:

s390/zcrypt: Fix memory leak with CCA cards used as accelerator

Tests showed that there is a memory leak if CCA cards are used as accelerator for clear key RSA requests (ME and CRT). With the last rework for the memory allocation the AP messages are allocated by apinitapmsg() but for some reason on two places (ME and CRT) the older allocation was still in place. So the first allocation simple was never freed.

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: validate doorbelloffset in user queue creation

amdgpuuserqgetdoorbellindex() passes the user-provided doorbelloffset to amdgpudoorbellindexonbar() without bounds checking. An arbitrarily large doorbelloffset can cause the calculated doorbell index to fall outside the allocated doorbell BO, potentially corrupting kernel doorbell space.

Validate that doorbelloffset falls within the doorbell BO before computing the BAR index, using u64 arithmetic to prevent overflow.

(cherry picked from commit de1ef4ffd70e1d15f0bf584fd22b1f28cbd5e2ec)

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix use of wrong skb when comparing queued RESP challenge serial

In rxrpcpostresponse(), the code should be comparing the challenge serial number from the cached response before deciding to switch to a newer response, but looks at the newer packet private data instead, rendering the comparison always false.

Fix this by switching to look at the older packet.

Fix further[1] to substitute the new packet in place of the old one if newer and also to release whichever we don't use.

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix RxGK token loading to check bounds

rxrpcpreparsexdryfsrxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through roundup(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, roundup() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged addkey() call.

Fix this by:

(1) Rejecting raw key lengths above AFSTOKENGKKEYMAX and raw ticket lengths above AFSTOKENGKTOKENMAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKENRKTIXMAX.

(2) Sizing the flexible-array allocation from the validated raw key length via structsizet() instead of the rounded value.

(3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse.

The control path (valid token with lengths within bounds) is unaffected.

In the Linux kernel, the following vulnerability has been resolved:

i2c: designware: amdisp: Fix resume-probe race condition issue

Identified resume-probe race condition in kernel v7.0 with the commit 38fa29b01a6a ("i2c: designware: Combine the init functions"),but this issue existed from the beginning though not detected.

The amdisp i2c device requires ISP to be in power-on state for probe to succeed. To meet this requirement, this device is added to genpd to control ISP power using runtime PM. The pmruntimegetsync() called before i2cdwprobe() triggers PM resume, which powers on ISP and also invokes the amdisp i2c runtime resume before the probe completes resulting in this race condition and a NULL dereferencing issue in v7.0

Fix this race condition by using the genpd APIs directly during probe: - Call devpmgenpdresume() to Power ON ISP before probe - Call devpmgenpdsuspend() to Power OFF ISP after probe - Set the device to suspended state with pmruntimesetsuspended() - Enable runtime PM only after the device is fully initialized

drm/amdgpu: add upper bound check on user inputs in wait ioctl

drm/amdgpu: add upper bound check on user inputs in signal ioctl

In the Linux kernel, the following vulnerability has been resolved:

writeback: don't block sync for filesystems with no data integrity guarantees

Add a SBINODATAINTEGRITY superblock flag for filesystems that cannot guarantee data persistence on sync (eg fuse). For superblocks with this flag set, sync kicks off writeback of dirty inodes but does not wait for the flusher threads to complete the writeback.

This replaces the per-inode ASNODATAINTEGRITY mapping flag added in commit f9a49aa302a0 ("fs/writeback: skip ASNODATAINTEGRITY mappings in waitsbinodes()"). The flag belongs at the superblock level because data integrity is a filesystem-wide property, not a per-inode one. Having this flag at the superblock level also allows us to skip having to iterate every dirty inode in waitsbinodes() only to skip each inode individually.

Prior to this commit, mappings with no data integrity guarantees skipped waiting on writeback completion but still waited on the flusher threads to finish initiating the writeback. Waiting on the flusher threads is unnecessary. This commit kicks off writeback but does not wait on the flusher threads. This change properly addresses a recent report [1] for a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting on the flusher threads to finish:

Workqueue: pmfssync pmfssyncworkfn Call Trace: <TASK> schedule+0x457/0x1720 schedule+0x27/0xd0 wbwaitforcompletion+0x97/0xe0 syncinodessb+0xf8/0x2e0 iteratesupers+0xdc/0x160 ksyssync+0x43/0xb0 pmfssyncworkfn+0x17/0xa0 processonework+0x193/0x350 workerthread+0x1a1/0x310 kthread+0xfc/0x240 retfromfork+0x243/0x280 retfromforkasm+0x1a/0x30 </TASK>

On fuse this is problematic because there are paths that may cause the flusher thread to block (eg if systemd freezes the user session cgroups first, which freezes the fuse daemon, before invoking the kernel suspend. The kernel suspend triggers ->writenode() which on fuse issues a synchronous setattr request, which cannot be processed since the daemon is frozen. Or if the daemon is buggy and cannot properly complete writeback, initiating writeback on a dirty folio already under writeback leads to writebackgetfolio() -> foliopreparewriteback() -> unconditional wait on writeback to finish, which will cause a hang). This commit restores fuse to its prior behavior before tmp folios were removed, where sync was essentially a no-op.

[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix leak of rxgk context in rxgkverifyresponse()

Fix rxgkverifyresponse() to clean up the rxgk context it creates.

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix leak of kobject name for sub-group spaceinfo

When createspaceinfosubgroup() allocates elements of spaceinfo->subgroup[], kobjectinitandadd() is called for each element via btrfssysfsaddspaceinfotype(). However, when checkremovingspaceinfo() frees these elements, it does not call btrfssysfsremovespaceinfo() on them. As a result, kobjectput() is not called and the associated kobj->name objects are leaked.

This memory leak is reproduced by running the blktests test case zbd/009 on kernels built with CONFIGDEBUGKMEMLEAK. The kmemleak feature reports the following error:

unreferenced object 0xffff888112877d40 (size 16): comm "mount", pid 1244, jiffies 4294996972 hex dump (first 16 bytes): 64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f data-reloc...... backtrace (crc 53ffde4d): kmallocnodetrackcallernoprof+0x619/0x870 kstrdup+0x42/0xc0 kobjectsetnamevargs+0x44/0x110 kobjectinitandadd+0xcf/0x150 btrfssysfsaddspaceinfotype+0xfc/0x210 [btrfs] createspaceinfosubgroup.constprop.0+0xfb/0x1b0 [btrfs] createspaceinfo+0x211/0x320 [btrfs] btrfsinitspaceinfo+0x15a/0x1b0 [btrfs] openctree+0x33c7/0x4a50 [btrfs] btrfsgettree.cold+0x9f/0x1ee [btrfs] vfsgettree+0x87/0x2f0 vfscmdcreate+0xbd/0x280 dosysfsconfig+0x3df/0x990 dosyscall64+0x136/0x1540 entrySYSCALL64afterhwframe+0x76/0x7e

To avoid the leak, call btrfssysfsremovespaceinfo() instead of kfree() for the elements.

In the Linux kernel, the following vulnerability has been resolved:

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

eventpoll: Fix semi-unbounded recursion

In the Linux kernel, the following vulnerability has been resolved:

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:

crashdump: don't log dm-crypt key bytes in readkeyfromuserkeying

When debug logging is enabled, readkeyfromuserkeying() logs the first 8 bytes of the key payload and partially exposes the dm-crypt key. Stop logging any key bytes.

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix key parsing memleak

In rxrpcpreparsexdryfsrxgk(), the memory attached to token->rxgk can be leaked in a few error paths after it's allocated.

Fix this by freeing it in the "rejecttoken:" case.

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix buffer overread in rxgkdoverifyauthenticator()

Fix rxgkdoverifyauthenticator() to check the buffer size before checking the nonce.

In the Linux kernel, the following vulnerability has been resolved:

In the Linux kernel, the following vulnerability has been resolved:

perf/x86: Fix potential bad containerof in intelpmuhwconfig

Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86hybridpmu and a containerof operation in intelpmusetacrcausedconstr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intelpmusetacrcausedconstr with an isx86event check.

In the Linux kernel, the following vulnerability has been resolved:

mux: mmio: fix regmap leak on probe failure

The mmio regmap that may be allocated during probe is never freed.

Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.

drm/amdgpu: validate user queue size constraints

In the Linux kernel, the following vulnerability has been resolved:

ovpn: tcp - fix packet extraction from stream

When processing TCP stream data in ovpntcprecv, we receive large cloned skbs from strprcv that may contain multiple coalesced packets. The current implementation has two bugs:

1. Header offset overflow: Using pskbpull with large offsets on coalesced skbs causes skb->data - skb->head to exceed the u16 storage of skb->networkheader. This causes skbresetnetworkheader to fail on the inner decapsulated packet, resulting in packet drops.

2. Unaligned protocol headers: Extracting packets from arbitrary positions within the coalesced TCP stream provides no alignment guarantees for the packet data causing performance penalties on architectures without efficient unaligned access. Additionally, openvpn's 2-byte length prefix on TCP packets causes the subsequent 4-byte opcode and packet ID fields to be inherently misaligned.

Fix both issues by allocating a new skb for each openvpn packet and using skbcopybits to extract only the packet content into the new buffer, skipping the 2-byte length prefix. Also, check the length before invoking the function that performs the allocation to avoid creating an invalid skb.

If the packet has to be forwarded to userspace the 2-byte prefix can be pushed to the head safely, without misalignment.

As a side effect, this approach also avoids the expensive linearization that pskbpull triggers on cloned skbs with page fragments. In testing, this resulted in TCP throughput improvements of up to 74%.