HID: lg-g15: cancel pending work on remove to fix a use-after-free

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

usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove

The threaded IRQ handler ccgirqhandler() calls ucsinotifycommon(), which on a connector-change event calls ucsiconnectorchange() and schedules connector work. In ucsiccgremove(), ucsidestroy() frees uc->ucsi (kfree) before freeirq() is called, so a handler invocation already in flight may access the freed object after ucsidestroy().

CPU 0 (remove) | CPU 1 (threaded IRQ) ucsidestroy(uc->ucsi) | ccgirqhandler() kfree(ucsi) // FREE | ucsinotifycommon(uc->ucsi) // USE

Move freeirq() before ucsidestroy() in the remove path. It is kept after ucsiunregister(): ucsiunregister() cancels connector work whose handler issues GETCONNECTORSTATUS through ucsisendcommandcommon(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled.

The probe error path already orders freeirq() before ucsidestroy().

This bug was found by static analysis.

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

crypto: nx - fix nxcryptoctxexit argument

nxcryptoctxshashexit calls nxcryptoctxexit with cryptoshashctx(...) but cryptoshashctx gives a nxcryptoctx , not a cryptotfm .

Fix the type in nxcryptoctxexit and drop the bogus cryptotfmctx call.

This fixes the following oops:

BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [#15] Call Trace: nxcryptoctxshashexit+0x24/0x60 cryptoshashexittfm+0x28/0x40 cryptodestroytfm+0x98/0x140 cryptoexitahashusingshash+0x20/0x40 cryptodestroytfm+0x98/0x140 hashrelease+0x1c/0x30 algsockdestruct+0x38/0x60 skdestruct+0x48/0x2b0 afalgrelease+0x58/0xb0 sockrelease+0x68/0x150 sockclose+0x20/0x40 fput+0x110/0x3a0 sysclose+0x48/0xa0 systemcallexception+0x140/0x2d0 systemcallcommon+0xf4/0x258

.. which came from hardlink(1) opportunistically using AFALG.

The same problem exists with nxcryptoctxskcipherexit getting a context it wasn't expecting, but apparently nobody hit that for years.

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

tipc: fix slab-use-after-free Read in tipcaeaddecryptdone

tipcaeaddecrypt() goes straight from tipcbearerhold(b) to cryptoaeaddecrypt(req) without taking a reference on the netns, unlike the encrypt path. When cryptoaeaddecrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipcaeaddecryptdone() later. If the bearer's netns is torn down in the meantime, cleanupnet() -> tipcexitnet() -> tipccryptostop() frees the per-netns tipccrypto, and the completion then reads it: tipcaeaddecryptdone() dereferences aead->crypto->stats and aead->crypto->net, and tipccryptorcvcomplete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.

Decoded KASAN splat (v7.1-rc7, CONFIGKASANINLINE + TIPC + TIPCCRYPTO):

BUG: KASAN: slab-use-after-free in tipcaeaddecryptdone (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: eventsunbound Call Trace: tipcaeaddecryptdone (net/tipc/crypto.c:999) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

Allocated by task 169: kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipccryptostart (net/tipc/crypto.c:1502) tipcinitnet (net/tipc/core.c:72) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:446) copynetns (net/core/netnamespace.c:579) createnewnamespaces (kernel/nsproxy.c:132) x64sysunshare (kernel/fork.c:3316) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

Freed by task 8: kfree (mm/slub.c:6566) tipcexitnet (net/tipc/core.c:119) cleanupnet (net/core/netnamespace.c:704) processonework (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436)

This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipcaeadencryptdone") fixed for the encrypt side. The encrypt path takes maybegetnet(aead->crypto->net) before cryptoaeadencrypt() and drops it with putnet() on the synchronous return paths and in tipcaeadencryptdone(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard.

Mirror the encrypt-side fix on the decrypt path: take a net reference before cryptoaeaddecrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with putnet() on the synchronous success/error return and at the end of tipcaeaddecryptdone().

Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipccryptostop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipcaeaddecryptdone() is the unpatched upstream path; tipcaeaddecrypt() still lacks maybegetnet(aead->crypto->net), so the completion can outlive the free on any config where cryptoaeaddecrypt() goes async.

Found by 0sec automated security-research tooling (https://0sec.ai).

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

net: phy: clean the sfp upstream if phy probing fails

Sashiko reported that we don't call sfpbusdelupstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events.

This issue existed before the generic phylib sfp support, back when drivers were calling physfpprobe themselves.

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

net: mvpp2: sync RX data at the hardware packet offset

mvpp2 programs the RX queue packet offset, so hardware writes received data at dmaaddr + MVPP2SKBHEADROOM. The current CPU sync starts at dmaaddr and only covers rxbytes + MVPP2MHSIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail.

On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame.

Use dmasyncsinglerangeforcpu() with MVPP2SKBHEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.

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

vsock: fix buffer size clamping order

In vsockupdatebuffersize(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint.

This breaks the intended socket memory boundaries by allowing the vsk->buffersize to grow beyond the configured vsk->buffermaxsize.

Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffermaxsize.

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

netfilter: flowtable: strictly check for maximum number of actions

The maximum number of flowtable hardware offload actions in IPv6 is:

ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)

Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.

Update flowactionentrynext() calls to check for the maximum number of supported actions.

While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.

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

octeontx2-af: Workaround SQM/PSE stalls by disabling sticky

NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated.

work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)

These changes are applied via NIXAFSQMDBGCTLSTATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.

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

usb: typec: ucsi: validate connector number in ucsinotifycommon()

The connector number extracted from CCI via UCSICCICONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsiconnectorchange(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries).

A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsiconnectorchange().

Add a bounds check in ucsinotifycommon(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.

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

openvswitch: validate MPLS set/setmasked payload length

validateset() accepted OVSKEYATTRMPLS as variable-sized payload for SET/SETMASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovskeympls).

Use the already normalized keylen (masked case included) and reject non-matching MPLS action key sizes.

Reject invalid MPLS action payload lengths early.

drm/i915/gt: fix refcount underflow in intelengineparkheartbeat

futex: Clear stale exiting pointer in futexlockpi() retry path

apparmor: Fix double free of nsname in aareplaceprofiles()

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

SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxyverf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.

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

mm/ksm: fix flag-dropping behavior in ksmmadvise

syzkaller discovered the following crash: (kernel BUG)

[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfdreleaseall+0x3a8/0x460

<snip other registers, drop unreliable trace>

[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfdrelease+0xef/0x1b0 [ 44.620976] fput+0x3f9/0xb60 [ 44.621240] fputclosesync+0x110/0x210 [ 44.622222] x64sysclose+0x8f/0x120 [ 44.622530] dosyscall64+0x5b/0x2f0 [ 44.622840] entrySYSCALL64afterhwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227

Kernel panics because it detects UFFD inconsistency during userfaultfdreleaseall(). Specifically, a VMA which has a valid pointer to vma->vmuserfaultfdctx, but no UFFD flags in vma->vmflags.

The inconsistency is caused in ksmmadvise(): when user calls madvise() with MADVUNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vmflags.

Assuming x8664 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VMMERGEABLE assignment.

VMMERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vmflags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.

Fix it by changing VMMERGEABLE constant to unsigned long, using the BIT() macro.

Note: other VM flags are not affected: This only happens to the VMMERGEABLE flag, as the other VM flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.

Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM)BUGON()s"), this is no longer a kernel BUG, but a WARNING at the same place:

[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067

but the root-cause (flag-drop) remains the same.

[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]

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>

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

wifi: mt7601u: fix an integer underflow

Fix an integer underflow that leads to a null pointer dereference in 'mt7601urxskbfromseg()'. The variable 'dmalen' in the URB packet could be manipulated, which could trigger an integer underflow of 'seglen' in 'mt7601urxprocessseg()'. This underflow subsequently causes the 'badframe' checks in 'mt7601urxskbfromseg()' to be bypassed, eventually leading to a dereference of the pointer 'p', which is a null pointer.

Ensure that 'dmalen' is greater than 'minseglen'.

Found by a modified version of syzkaller.

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+ #139 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:skbaddrxfrag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: mt7601urxtasklet+0xc73/0x1270 ? mt7601usubmitrxbuf.isra.0+0x510/0x510 ? taskletactioncommon.isra.0+0x79/0x2f0 taskletactioncommon.isra.0+0x206/0x2f0 dosoftirq+0x1b5/0x880 ? taskletunlock+0x30/0x30 runksoftirqd+0x26/0x50 smpbootthreadfn+0x34f/0x7d0 ? smpbootregisterpercputhread+0x370/0x370 kthread+0x3a1/0x480 ? setkthreadstruct+0x120/0x120 retfromfork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 57f34f93b4da0f9b ]--- RIP: 0010:skbaddrxfrag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554

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

scsi: target: iscsi: Fix buffer overflow in liotargetnaclinfoshow()

The function liotargetnaclinfoshow() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory.

This patch replaces sprintf() with sysfsemitat() that checks for buffer boundries.

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

scsi: ses: Fix possible descptr out-of-bounds accesses

Sanitize possible descptr out-of-bounds accesses in sesenclosuredataprocess().

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

ring-buffer: Fix deadloop issue on reading tracepipe

Soft lockup occurs when reading file 'tracepipe':

watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ringbufferemptycpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: findnextentry+0x1a8/0x4b0 ? peeknextentry+0x250/0x250 ? downwrite+0xa5/0x120 ? downwritekillable+0x130/0x130 tracefindnextentryinc+0x3b/0x1d0 tracingreadpipe+0x423/0xae0 ? tracingsplicereadpipe+0xcb0/0xcb0 vfsread+0x16b/0x490 ksysread+0x105/0x210 ? ia32syspwrite64+0x200/0x200 ? switchfpureturn+0x108/0x220 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x61/0xc6

Through the vmcore, I found it's because in tracingreadpipe(), ringbufferemptycpu() found some buffer is not empty but then it cannot read anything due to "rbnumofentries() == 0" always true, Then it infinitely loop the procedure due to user buffer not been filled, see following code path:

tracingreadpipe() { ... ... waitagain: tracingwaitpipe() // 1. find non-empty buffer here tracefindnextentryinc() // 2. loop here try to find an entry findnextentry() ringbufferemptycpu(); // 3. find non-empty buffer peeknextentry() // 4. but peek always return NULL ringbufferpeek() rbbufferpeek() rbgetreaderpage() // 5. because rbnumofentries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }

By some analyzing, I found that when resetting ringbuffer, the 'entries' of its pages are not all cleared (see rbresetcpu()). Then when reducing the ringbuffer, and if some reduced pages exist dirty 'entries' data, they will be added into 'cpubuffer->overrun' (see rbremovepages()), which cause wrong 'overrun' count and eventually cause the deadloop issue.

To fix it, we need to clear every pages in rbresetcpu().

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

tipc: fix a null-ptr-deref in tipctopsrvaccept

syzbot found a crash in tipctopsrvaccept:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipcrcv tipctopsrvaccept RIP: 0010:kernelaccept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipctopsrvaccept+0x197/0x280 net/tipc/topsrv.c:460 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306

It was caused by srv->listener that might be set to null by tipctopsrvstop() in net .exit whereas it's still used in tipctopsrvaccept() worker.

srv->listener is protected by srv->idrlock in tipctopsrvstop(), so add a check for srv->listener under srv->idrlock in tipctopsrvaccept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipctopsrvaccept(), move sockrelease() after tipctopsrvworkstop() where it's waiting until the tipctopsrvaccept worker to be done.

Note that skcallbacklock is used to protect sk->skuserdata instead of srv->listener, and it should check srv in tipctopsrvlistenerdataready() instead. This also ensures that no more tipctopsrvaccept worker will be started after tipcconnclose() is called in tipctopsrvstop() where it sets sk->skuserdata to null.

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

wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmffwallocrequest()

This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITSPERTYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmfusbprobecb() or brcmfusbresetresume(), for example.

Found by a modified version of syzkaller.

UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d ubsanepilogue+0x5/0x40 ubsanhandleshiftoutofbounds.cold+0x53/0xdb ? lockchaincount+0x20/0x20 brcmffwallocrequest.cold+0x19/0x3ea ? brcmffwgetfirmwares+0x250/0x250 ? brcmfusbioctlrespwait+0x1a7/0x1f0 brcmfusbgetfwname+0x114/0x1a0 ? brcmfusbresetresume+0x120/0x120 ? number+0x6c4/0x9a0 brcmfcprocessclmblob+0x168/0x590 ? putdec+0x90/0x90 ? enableptrkeyworkfn+0x20/0x20 ? brcmfcommonpdremove+0x50/0x50 ? rcureadlockschedheld+0xa1/0xd0 brcmfcpreinitdcmds+0x673/0xc40 ? brcmfcsetjoinprefdefault+0x100/0x100 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockacquire+0x19d/0x4e0 ? findheldlock+0x2d/0x110 ? brcmfusbdeq+0x1cc/0x260 ? markheldlocks+0x9f/0xe0 ? lockdephardirqsonprepare+0x273/0x3e0 ? rawspinunlockirqrestore+0x47/0x50 ? tracehardirqson+0x1c/0x120 ? brcmfusbdeq+0x1a7/0x260 ? brcmfusbrxfillall+0x5a/0xf0 brcmfattach+0x246/0xd40 ? wiphynewnm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmfusbprobe+0x12de/0x1690 ? brcmfusbdevqinit.constprop.0+0x470/0x470 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 ? usbmatchid.part.0+0x88/0xc0 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? mutexunlockslowpath+0xe7/0x660 ? fwdevlinklinktosuppliers+0x550/0x550 usbsetconfiguration+0x984/0x1770 ? kernfscreatelink+0x175/0x230 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? fwdevlinklinktosuppliers+0x550/0x550 usbnewdevice.cold+0x463/0xf66 ? hubdisconnect+0x400/0x400 ? rawspinunlockirq+0x24/0x30 hubevent+0x10d5/0x3330 ? hubportdebounce+0x280/0x280 ? lockacquire+0x1671/0x5790 ? wqcalcnodecpumask+0x170/0x2a0 ? lockrelease+0x640/0x640 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockdephardirqsonprepare+0x273/0x3e0 processonework+0x873/0x13e0 ? lockrelease+0x640/0x640 ? pwqdecnrinflight+0x320/0x320 ? rwlockbug.part.0+0x90/0x90 workerthread+0x8b/0xd10 ? kthreadparkme+0xd9/0x1d0 ? pr ---truncated---

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

media: si470x: Fix use-after-free in si470xintincallback()

syzbot reported use-after-free in si470xintincallback() [1]. This indicates that urb->context, which contains struct si470xdevice object, is freed when si470xintincallback() is called.

The cause of this issue is that si470xintincallback() is called for freed urb.

si470xusbdriverprobe() calls si470xstartusb(), which then calls usbsubmiturb() and si470xstart(). If si470xstartusb() fails, si470xusbdriverprobe() doesn't kill urb, but it just frees struct si470xdevice object, as depicted below:

si470xusbdriverprobe() ... si470xstartusb() ... usbsubmiturb() retval = si470xstart() return retval if (retval < 0) free struct si470xdevice object, but don't kill urb

This patch fixes this issue by killing urb when si470xstartusb() fails and urb is submitted. If si470xstartusb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470xdevice object.

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

gfs2: Fix possible data races in gfs2showoptions()

Some fields such as gtlogdsecs of the struct gfs2tune are accessed without holding the lock gtspin in gfs2showoptions():

val = sdp->sdtune.gtlogdsecs; if (val != 30) seqprintf(s, ",commit=%d", val);

And thus can cause data races when gfs2showoptions() and other functions such as gfs2reconfigure() are concurrently executed:

spinlock(&gt->gtspin); gt->gtlogdsecs = newargs->arcommit;

To fix these possible data races, the lock sdp->sdtune.gtspin is acquired before accessing the fields of gfs2tune and released after these accesses.

Further changes by Andreas:

- Don't hold the spin lock over the seqprintf operations.

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

netfilter: conntrack: Avoid nfcthelperhash uses after free

If nfconntrackinitstart() fails (for example due to a registernfconntrackbpf() failure), the nfconntrackhelperfini() clean-up path frees the nfcthelperhash map.

When built with NFCONNTRACK=y, further netfilter modules (e.g: netfilterconntrackftp) can still be loaded and call nfconntrackhelpersregister(), independently of whether nfconntrack initialized correctly. This accesses the nfcthelperhash dangling pointer and causes a uaf, possibly leading to random memory corruption.

This patch guards nfconntrackhelperregister() from accessing a freed or uninitialized nfcthelperhash pointer and fixes possible uses-after-free when loading a conntrack module.

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

jfs: fix invalid free of JFSIP(ipimap)->iimap in diUnmount

syzbot found an invalid-free in diUnmount:

BUG: KASAN: double-free in slabfree mm/slub.c:3661 [inline] BUG: KASAN: double-free in kmemcachefree+0x71/0x110 mm/slub.c:3674 Free of addr ffff88806f410000 by task syz-executor131/3632

CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreportinvalidfree+0xac/0xd0 mm/kasan/report.c:460 kasanslabfree+0xfb/0x120 kasanslabfree include/linux/kasan.h:177 [inline] slabfreehook mm/slub.c:1724 [inline] slabfreefreelisthook+0x12e/0x1a0 mm/slub.c:1750 slabfree mm/slub.c:3661 [inline] kmemcachefree+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfsimap.c:195 jfsumount+0x108/0x370 fs/jfs/jfsumount.c:63 jfsputsuper+0x86/0x190 fs/jfs/super.c:194 genericshutdownsuper+0x130/0x310 fs/super.c:492 killblocksuper+0x79/0xd0 fs/super.c:1428 deactivatelockedsuper+0xa7/0xf0 fs/super.c:332 cleanupmnt+0x494/0x520 fs/namespace.c:1186 taskworkrun+0x243/0x300 kernel/taskwork.c:179 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x664/0x2070 kernel/exit.c:820 dogroupexit+0x1fd/0x2b0 kernel/exit.c:950 dosysexitgroup kernel/exit.c:961 [inline] sesysexitgroup kernel/exit.c:959 [inline] x64sysexitgroup+0x3b/0x40 kernel/exit.c:959 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd [...]

JFSIP(ipimap)->iimap is not setting to NULL after free in diUnmount. If jfsremount() free JFSIP(ipimap)->iimap but then failed at diMount(). JFSIP(ipimap)->iimap will be freed once again. Fix this problem by setting JFSIP(ipimap)->iimap to NULL after free.

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

scsi: qla2xxx: Fix deletion race condition

System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu.

20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4type 1

Move the clearing/setting of deleted flag lock.

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

nilfs2: fix potential UAF of struct nilfsscinfo in nilfssegctorthread()

The finalization of nilfssegctorthread() can race with nilfssegctorkillthread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected.

At the end of nilfssegctorthread(), it assigns NULL to "sctask" member of "struct nilfsscinfo" to indicate the thread has finished, and then notifies nilfssegctorkillthread() of this using waitqueue "scwaittask" on the struct nilfsscinfo.

However, here, immediately after the NULL assignment to "sctask", it is possible that nilfssegctorkillthread() will detect it and return to continue the deallocation, freeing the nilfsscinfo structure before the thread does the notification.

This fixes the issue by protecting the NULL assignment to "sctask" and its notification, with spinlock "scstatelock" of the struct nilfsscinfo. Since nilfssegctorkillthread() does a final check to see if "sctask" is NULL with "scstatelock" locked, this can eliminate the race.

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

dm integrity: call kmemcachedestroy() in dmintegrityinit() error path

Otherwise the journaliocache will leak if dmregistertarget() fails.