drm/vmwgfx: bound DMA command body size against suffix pointer

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

usb: musb: omap2430: Do not put borrowed ofnode in probe

omap2430probe() stores pdev->dev.ofnode in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it.

The success and error paths nevertheless call ofnodeput(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.ofnode with an unbalanced reference count.

Do not put the borrowed platform device node from omap2430probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.

HID: multitouch: fix out-of-bounds bit access on mtioflags

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

net: pull headers in qdiscpktlensegsinit()

Most ndostartxmit() methods expects headers of gso packets to be already in skb->head.

net/core/tso.c users are particularly at risk, because tsobuildhdr() does a memcpy(hdr, skb->data, hdrlen);

qdiscpktlensegsinit() already does a dissection of gso packets.

Use pskbmaypull() instead of skbheaderpointer() to make sure drivers do not have to reimplement this.

Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKBDROPREASONSKBBADGSO dropreason.

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

net: pull headers in qdiscpktlensegsinit()

Most ndostartxmit() methods expects headers of gso packets to be already in skb->head.

net/core/tso.c users are particularly at risk, because tsobuildhdr() does a memcpy(hdr, skb->data, hdrlen);

qdiscpktlensegsinit() already does a dissection of gso packets.

Use pskbmaypull() instead of skbheaderpointer() to make sure drivers do not have to reimplement this.

Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKBDROPREASONSKBBADGSO dropreason.

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

crypto: ccp - copy IV using skcipher ivsize

AFALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use cryptoskcipherivsize() to copy only the algorithm's IV length.

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

ice: fix double-free of txbuf skb

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

netfilter: nat: use kfreercu to release ops

Florian Westphal says:

"Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nfhookops that are used to register the callbacks.

However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.

This code will peek back into the nfhookops that are available at the tail of the pointer-array blob used by the datapath.

The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.

But once that changes the nat ops structures have to be deferred too."

Update nfnatregisterfn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlinkhook.

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

netfilter: nftsetpipapoavx2: don't return non-matching entry on expiry

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo.

This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

We successfully re-inserted a . b c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching element only considering the first field,

i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nftpipapoavx2lookupslow' fallback.

Bisection points to 7711f4bb4b36 ("netfilter: nftsetpipapo: fix range overlap detection") but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.

can: bcm: switch timer to HRTIMERMODESOFT and remove hrtimertasklet commit bf74aa86e111aa3b2fbb25db37e3a3fab71b5b68

This patch switches the timer to HRTIMERMODESOFT, which executed the timer callback in softirq context and removes the hrtimertasklet.

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

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

crypto: algifaead - Revert to operating out-of-place

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

proc: protect ptracemayaccess() with execupdatelock (FD links)

procpidgetlink() and procpidreadlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways.

To fix it, pass the task to the ->procgetlink() handler, and instead of procfdaccessallowed(), introduce a new helper callprocgetlink() that looks up and locks the task, does the access check, and calls ->procgetlink().

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

smb: client: harden POSIX SID length parsing

posixinfosidsize() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.

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

net, bpf: check master for NULL in xdpmasterredirect()

xdpmasterredirect() dereferences the result of netdevmasterupperdevgetrcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency.

The reach guard only checks netifisbondslave(). On bond slave release bondupperdevunlink() drops the upper-master adjacency before clearing IFFSLAVE, so an XDPTX reaching xdpmasterredirect() in that window still passes netifisbondslave() while master is already NULL, and faults on master->flags at offset 0xb0:

BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdpmasterredirect (net/core/filter.c:4432) Call Trace: xdpmasterredirect (net/core/filter.c:4432) bpfprogrungenericxdp (include/net/xdp.h:700) doxdpgeneric (net/core/dev.c:5608) netifreceiveskbonecore (net/core/dev.c:6204) processbacklog (net/core/dev.c:6319) napipoll (net/core/dev.c:7729) netrxaction (net/core/dev.c:7792) handlesoftirqs (kernel/softirq.c:622) devqueuexmit (include/linux/bottomhalf.h:33) packetsendmsg (net/packet/afpacket.c:3082) syssendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt

The missing check dates back to the original code; commit 1921f91298d1 ("net, bpf: fix null-ptr-deref in xdpmasterredirect() for down master") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.

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

ipv4: igmp: remove multicast group from hash table on device destruction

When a device is destroyed under RTNL, ipmcdestroydev() iterates through the multicast list and calls ipmaput() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mchash).

Since the device remains published in dev->ipptr until after ipmcdestroydev() completes, concurrent RCU readers traversing mchash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs.

Fix this by unlinking the multicast group from mchash using ipmchashremove() before scheduling it for reclamation.

BUG: KASAN: slab-use-after-free in ipcheckmcrcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276

Call Trace: <IRQ> dumpstacklvl+0x67/0x90 printreport+0x175/0x7c0 kasanreport+0x147/0x180 ipcheckmcrcu+0x149/0x3f0 udpv4earlydemux+0x36d/0x12d0 iprcvfinishcore+0xb8b/0x1390 iprcvfinish+0x54/0x120 NFHOOK+0x213/0x2b0 netifreceiveskb+0x126/0x340 processbacklog+0x4f2/0xf00 napipoll+0x92/0x2c0 netrxaction+0x583/0xc60 handlesoftirqs+0x236/0x7f0 dosoftirq+0x57/0x80 </IRQ>

Allocated by task 2239: kasansavetrack+0x3e/0x80 kasankmalloc+0x72/0x90 ipmcincgroup+0x31a/0xa40 ipmcjoingroup+0x334/0x3f0 doipsetsockopt+0x16fa/0x2010 ipsetsockopt+0x3f/0x90 dosocksetsockopt+0x1ad/0x300

Freed by task 0: kasansavetrack+0x3e/0x80 kasansavefreeinfo+0x40/0x50 kasanslabfree+0x3a/0x60 rcufreesheafprepare+0xd4/0x220 rcufreesheaf+0x36/0x190 rcucore+0x8d9/0x12f0 handlesoftirqs+0x236/0x7f0

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

isofs: bound Rock Ridge symlink components to the SL record

getsymlinkchunk() and the SL handling in parserockridgeinodeinternal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and getsymlinkchunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.

A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; getsymlinkchunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.

ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAPSYSADMIN - so the record contents are attacker-controlled.

Reject any component that does not fit in the remaining record bytes before using it. In getsymlinkchunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parserockridgeinodeinternal() stop the inode-size walk.

block: Avoid mounting the bdev pseudo-filesystem in userspace

i2c: core: fix adapter registration race

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

fs/buffer: fix use-after-free when call bhread() helper

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.

eventpoll: Fix semi-unbounded recursion

ext4: fix out-of-bound read in ext4xattrinodedecrefall()

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

net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105tabledeleteentry()

There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds.

The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.

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

netfilter: nfttunnel: fix geneveopt type confusion addition

When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char .

However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.

[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] syssendmsg+0xfd/0x170 [ 7.003145] syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8

Fix this bug with correct pointer addition and conversion in parse and dump code.

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

ovl: fix UAF in ovldentryupdatereval by moving dput() in ovllinkup

The issue was caused by dput(upper) being called before ovldentryupdatereval(), while upper->dflags was still accessed in ovldentryremote().

Move dput(upper) after its last use to prevent use-after-free.

BUG: KASAN: slab-use-after-free in ovldentryremote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovldentryupdatereval+0xd2/0xf0 fs/overlayfs/util.c:167

Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 ovldentryremote fs/overlayfs/util.c:162 [inline] ovldentryupdatereval+0xd2/0xf0 fs/overlayfs/util.c:167 ovllinkup fs/overlayfs/copyup.c:610 [inline] ovlcopyupone+0x2105/0x3490 fs/overlayfs/copyup.c:1170 ovlcopyupflags+0x18d/0x200 fs/overlayfs/copyup.c:1223 ovlrename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfsrename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>

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

bpf, testrun: Fix use-after-free issue in ethskbpkttype()

KMSAN reported a use-after-free issue in ethskbpkttype()[1]. The cause of the issue was that ethskbpkttype() accessed skb's data that didn't contain an Ethernet header. This occurs when bpfprogtestrunxdp() passes an invalid value as the userdata argument to bpftestinit().

Fix this by returning an error when userdata is less than ETHHLEN in bpftestinit(). Additionally, remove the check for "if (usersize > size)" as it is unnecessary.

[1] BUG: KMSAN: use-after-free in ethskbpkttype include/linux/etherdevice.h:627 [inline] BUG: KMSAN: use-after-free in ethtypetrans+0x4ee/0x980 net/ethernet/eth.c:165 ethskbpkttype include/linux/etherdevice.h:627 [inline] ethtypetrans+0x4ee/0x980 net/ethernet/eth.c:165 xdpbuildskbfromframe+0x5a8/0xa50 net/core/xdp.c:635 xdprecvframes net/bpf/testrun.c:272 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2954/0x3330 net/bpf/testrun.c:390 bpfprogtestrunxdp+0x148e/0x1b10 net/bpf/testrun.c:1318 bpfprogtestrun+0x5b7/0xa30 kernel/bpf/syscall.c:4371 sysbpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777 dosysbpf kernel/bpf/syscall.c:5866 [inline] sesysbpf kernel/bpf/syscall.c:5864 [inline] x64sysbpf+0xa4/0xf0 kernel/bpf/syscall.c:5864 x64syscall+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: freepagesprepare mm/pagealloc.c:1056 [inline] freeunrefpage+0x156/0x1320 mm/pagealloc.c:2657 freepages+0xa3/0x1b0 mm/pagealloc.c:4838 bpfringbuffree kernel/bpf/ringbuf.c:226 [inline] ringbufmapfree+0xff/0x1e0 kernel/bpf/ringbuf.c:235 bpfmapfree kernel/bpf/syscall.c:838 [inline] bpfmapfreedeferred+0x17c/0x310 kernel/bpf/syscall.c:862 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa2b/0x1b60 kernel/workqueue.c:3310 workerthread+0xedf/0x1550 kernel/workqueue.c:3391 kthread+0x535/0x6b0 kernel/kthread.c:389 retfromfork+0x6e/0x90 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

drm/amdgpu: avoid buffer overflow attach in smusyssetpptable()