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

sock: redo the psock vs ULP protection check

Commit 8a59f9d1e3d4 ("sock: Introduce sk->skprot->psockupdateskprot()") has moved the inetcskhasulp(sk) check from skpsockinit() to the new tcpbpfupdateproto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets.

Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the skpsockinit() itself. Otherwise if ULP is already present we'll notice that later, and call tcpupdateulp() with the skproto of the ULP itself, which will most likely result in the ULP looping its callbacks.

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

ata: libata-core: fix NULL pointer deref in atahostallocpinfo()

In an unlikely (and probably wrong?) case that the 'ppi' parameter of atahostallocpinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&atadummyportinfo' to fix the possible kernel oops for good...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.

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

nfc: nfcmrvl: Fix memory leak in nfcmrvlplaydeferred

Similar to the handling of playdeferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in playdeferred"), we thought a patch might be needed here as well.

Currently usbsubmiturb is called directly to submit deferred tx urbs after unanchor them.

So the usbgivebackurbbh would failed to unref it in usbunanchorurb and cause memory leak.

Put those urbs in txanchor to avoid the leak, and also fix the error handling.

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

ipv6: Fix signed integer overflow in ip6appenddata

Resurrect ubsan overflow checks and ubsan report this warning, fix it by change the variable [length] type to sizet.

UBSAN: signed-integer-overflow in net/ipv6/ip6output.c:1489:19 2147479552 + 8567 cannot be represented in type 'int' CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1 Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0x214/0x230 showstack+0x30/0x78 dumpstacklvl+0xf8/0x118 dumpstack+0x18/0x30 ubsanepilogue+0x18/0x60 handleoverflow+0xd0/0xf0 ubsanhandleaddoverflow+0x34/0x44 ip6appenddata.isra.48+0x1598/0x1688 ip6appenddata+0x128/0x260 udpv6sendmsg+0x680/0xdd0 inet6sendmsg+0x54/0x90 socksendmsg+0x70/0x88 syssendmsg+0xe8/0x368 syssendmsg+0x98/0xe0 syssendmmsg+0xf4/0x3b8 arm64syssendmmsg+0x34/0x48 invokesyscall+0x64/0x160 el0svccommon.constprop.4+0x124/0x300 doel0svc+0x44/0xc8 el0svc+0x3c/0x1e8 el0t64synchandler+0x88/0xb0 el0t64sync+0x16c/0x170

Changes since v1: -Change the variable [length] type to unsigned, as Eric Dumazet suggested. Changes since v2: -Don't change exthdrlen type in ip6makeskb, as Paolo Abeni suggested. Changes since v3: -Don't change ulen type in udpv6sendmsg and l2tpip6sendmsg, as Jakub Kicinski suggested.

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

ipv6: Fix signed integer overflow in l2tpip6sendmsg

When len >= INTMAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.

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

clocksource: hyper-v: unexport init-annotated hvinitclocksource()

EXPORTSYMBOL and init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated init. The access to a freed symbol may end up with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds.

There are two ways to fix it:

- Remove init - Remove EXPORTSYMBOL

I chose the latter for this case because the only in-tree call-site, arch/x86/kernel/cpu/mshyperv.c is never compiled as modular. (CONFIGHYPERVISORGUEST is boolean)

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

drm/i915/reset: Fix errorstateread ptr + offset use

Fix our pointer offset usage in errorstateread when there is no i915gpucoredump but buf offset is non-zero.

This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 errorstate dump while the other is forcing full GT resets. (takes a while to trigger).

The dmesg call trace:

[ 5590.803000] BUG: unable to handle page fault for address: ffffffffa0b0e000 [ 5590.803009] #PF: supervisor read access in kernel mode [ 5590.803013] #PF: errorcode(0x0000) - not-present page [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067 PTE 0 [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 5590.803026] CPU: 5 PID: 13656 Comm: i915hangman Tainted: G U 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136 [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00. 3031.A02.2201171222 01/17/2022 [ 5590.803039] RIP: 0010:memcpyerms+0x6/0x10 [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282 [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00 RCX: 0000000000000f8f [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000 RDI: ffff888107ee9071 [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000019 [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000 R15: ffff888107ee9000 [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000) knlGS:0000000000000000 [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004 CR4: 0000000000770ee0 [ 5590.803089] PKRU: 55555554 [ 5590.803091] Call Trace: [ 5590.803093] <TASK> [ 5590.803096] errorstateread+0xa1/0xd0 [i915] [ 5590.803175] kernfsfopreaditer+0xb2/0x1b0 [ 5590.803180] newsyncread+0x116/0x1a0 [ 5590.803185] vfsread+0x114/0x1b0 [ 5590.803189] ksysread+0x63/0xe0 [ 5590.803193] dosyscall64+0x38/0xc0 [ 5590.803197] entrySYSCALL64afterhwframe+0x44/0xae [ 5590.803201] RIP: 0033:0x7f62aaea5912 [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000 RCX: 00007f62aaea5912 [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f RDI: 0000000000000006 [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010 R09: 0000000000101000 [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000006 [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010 R15: 0000000000200000 [ 5590.803238] </TASK> [ 5590.803240] Modules linked in: i915 ttm drmbuddy drmdphelper drmkmshelper syscopyarea sysfillrect sysimgblt fbsysfops primenumbers nfnetlink brnetfilter overlay meipxp meihdcp x86pkgtempthermal coretemp kvmintel sndhdacodechdmi sndhdaintel ---truncated---

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

arm64: ftrace: consistently handle PLTs.

Sometimes it is necessary to use a PLT entry to call an ftrace trampoline. This is handled by ftracemakecall() and ftracemakenop(), with each having almost identical logic, but this is not handled by ftracemodifycall() since its introduction in commit:

3b23e4991fb66f6d ("arm64: implement ftrace with regs")

Due to this, if we ever were to call ftracemodifycall() for a callsite which requires a PLT entry for a trampoline, then either:

a) If the old addr requires a trampoline, ftracemodifycall() will use an out-of-range address to generate the 'old' branch instruction. This will result in warnings from aarch64insngenbranchimm() and ftracemodifycode(), and no instructions will be modified. As ftracemodifycall() will return an error, this will result in subsequent internal ftrace errors.

b) If the old addr does not require a trampoline, but the new addr does, ftracemodifycall() will use an out-of-range address to generate the 'new' branch instruction. This will result in warnings from aarch64insngenbranchimm(), and ftracemodifycode() will replace the 'old' branch with a BRK. This will result in a kernel panic when this BRK is later executed.

Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don't necessarily affect the rest of the system. This can be demonstrated with an out-of-tree test module which triggers ftracemodifycall(), e.g.

| # insmod testftrace.ko | testftrace: Function testfunction raw=0xffffb3749399201c, callsite=0xffffb37493992024 | branchimmcommon: offset out of range | branchimmcommon: offset out of range | ------------[ ftrace bug ]------------ | ftrace failed to modify | [<ffffb37493992024>] testfunction+0x8/0x38 [testftrace] | actual: 1d:00:00:94 | Updating ftrace call site to call a different ftrace function | ftrace record flags: e0000002 | (2) R | expected tramp: ffffb374ae42ed54 | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftracebug+0x280/0x2b0 | Modules linked in: testftrace(+) | CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13 | Hardware name: linux,dummy-virt (DT) | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftracebug+0x280/0x2b0 | lr : ftracebug+0x280/0x2b0 | sp : ffff80000839ba00 | x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0 | x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000 | x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8 | x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff | x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4 | x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8 | x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167 | x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022 | Call trace: | ftracebug+0x280/0x2b0 | ftracereplacecode+0x98/0xa0 | ftracemodifyallcode+0xe0/0x144 | archftraceupdatecode+0x14/0x20 | ftracestartup+0xf8/0x1b0 | registerftracefunction+0x38/0x90 | testftraceinit+0xd0/0x1000 [testftrace] | dooneinitcall+0x50/0x2b0 | doinitmodule+0x50/0x1f0 | loadmodule+0x17c8/0x1d64 | dosysfinitmodule+0xa8/0x100 | arm64sysfinitmodule+0x2c/0x3c | invokesyscall+0x50/0x120 | el0svccommon.constprop.0+0xdc/0x100 | doel0svc+0x3c/0xd0 | el0svc+0x34/0xb0 | el0t64synchandler+0xbc/0x140 | el0t64sync+0x18c/0x190 | ---[ end trace 0000000000000000 ]---

We can solve this by consistently determining whether to use a PLT entry for an address.

Note that since (the earlier) commit:

f1a54ae9 ---truncated---

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

irqchip/gic/realview: Fix refcount leak in realviewgicofinit

offindmatchingnodeandmatch() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

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

irqchip/apple-aic: Fix refcount leak in aicoficinit

ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

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

irqchip/apple-aic: Fix refcount leak in buildfiqaffinity

offindnodebyphandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

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

irqchip/gic-v3: Fix error handling in gicpopulateppipartitions

ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. When kcalloc fails, it missing ofnodeput() and results in refcount leak. Fix this by goto outputnode label.

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

irqchip/gic-v3: Fix refcount leak in gicpopulateppipartitions

offindnodebyphandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

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

irqchip/realtek-rtl: Fix refcount leak in mapinterrupts

offindnodebyphandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. This function doesn't call ofnodeput() in error path. Call ofnodeput() directly after ofpropertyreadu32() to cover both normal path and error path.

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

usb: dwc2: Fix memory leak in dwc2hcdinit

usbcreatehcd will alloc memory for hcd, and we should call usbputhcd to free it when platformgetresource() fails to prevent memory leak. goto error2 label instead error1 to fix this.

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

usb: gadget: lpc32xxudc: Fix refcount leak in lpc32xxudcprobe

ofparsephandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak. ofnodeput() will check NULL pointer.

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

dm mirror log: round up region bitmap size to BITSPERLONG

The code in dm-log rounds up bitsetsize to 32 bits. It then uses findnextzerobitle on the allocated region. findnextzerobitle accesses the bitmap using unsigned long pointers. So, on 64-bit architectures, it may access 4 bytes beyond the allocated size.

Fix this bug by rounding up bitsetsize to BITSPERLONG.

This bug was found by running the lvm2 testsuite with kasan.

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

cfi: Fix cfislowpathdiag RCU usage with cpuidle

RCUNONIDLE usage during cfislowpathdiag can result in an invalid RCU state in the cpuidle code path:

WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcueqsenter+0xe4/0x138 ... Call trace: rcueqsenter+0xe4/0x138 rcuidleenter+0xa8/0x100 cpuidleenterstate+0x154/0x3a8 cpuidleenter+0x3c/0x58 doidle.llvm.6590768638138871020+0x1f4/0x2ec cpustartupentry+0x28/0x2c secondarystartkernel+0x1b8/0x220 secondaryswitched+0x94/0x98

Instead, call rcuirqenter/exit to wake up RCU only when needed and disable interrupts for the entire CFI shadow/module check when we do.

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

ext4: fix bugon ext4mbuseinodepa

Hulk Robot reported a BUGON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4mbmarkdiskspaceused.cold+0x85/0x136f [...] Call Trace: ext4mbnewblocks+0x9df/0x5d30 ext4extmapblocks+0x1803/0x4d80 ext4mapblocks+0x3a4/0x1a10 ext4writepages+0x126d/0x2c30 dowritepages+0x7f/0x1b0 filemapfdatawriterange+0x285/0x3b0 filewriteandwaitrange+0xb1/0x140 ext4syncfile+0x1aa/0xca0 vfsfsyncrange+0xfb/0x260 dofsync+0x48/0xa0 [...] ==================================================================

Above issue may happen as follows: ------------------------------------- dofsync vfsfsyncrange ext4syncfile filewriteandwaitrange filemapfdatawriterange dowritepages ext4writepages mpagemapandsubmitextent mpagemaponeextent ext4mapblocks ext4mbnewblocks ext4mbnormalizerequest >>> start + size <= ac->acoex.felogical ext4mbregularallocator ext4mbsimplescangroup ext4mbusebestfound ext4mbnewpreallocation ext4mbnewinodepa ext4mbuseinodepa >>> set ac->acbex.felen <= 0 ext4mbmarkdiskspaceused >>> BUGON(ac->acbex.felen <= 0);

we can easily reproduce this problem with the following commands: fallocate -l100M disk mkfs.ext4 -b 1024 -g 256 disk mount disk /mnt fsstress -d /mnt -l 0 -n 1000 -p 1

The size must be smaller than or equal to EXT4BLOCKSPERGROUP. Therefore, "start + size <= ac->acoex.felogical" may occur when the size is truncated. So start should be the start position of the group where acoex.felogical is located after alignment. In addition, when the value of felogical or EXT4BLOCKSPERGROUP is very large, the value calculated by startoff is more accurate.

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

ext4: add reserved GDT blocks check

We capture a NULL pointer issue when resizing a corrupt ext4 image which is freshly clear resizeinode feature (not run e2fsck). It could be simply reproduced by following steps. The problem is because of the resizeinode feature was cleared, and it will convert the filesystem to metabg mode in ext4resizefs(), but the es->sreservedgdtblocks was not reduced to zero, so could we mistakenly call reservebackupgdb() and passing an uninitialized resizeinode to it when adding new group descriptors.

mkfs.ext4 /dev/sda 3G tune2fs -O ^resizeinode /dev/sda #forget to run requested e2fsck mount /dev/sda /mnt resize2fs /dev/sda 8G

======== BUG: kernel NULL pointer dereference, address: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4flexgroupadd+0xe08/0x2570 ... Call Trace: <TASK> ext4resizefs+0xbec/0x1660 ext4ioctl+0x1749/0x24e0 ext4ioctl+0x12/0x20 x64sysioctl+0xa6/0x110 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ========

The fix is simple, add a check in ext4resizebegin() to make sure that the es->sreservedgdtblocks is zero when the resizeinode feature is disabled.

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

9p: fix fid refcount leak in v9fsvfsatomicopendotl

We need to release directory fid if we fail halfway through open

This fixes fid leaking with xfstests generic 531

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

9p: fix fid refcount leak in v9fsvfsgetlink

we check for protocol version later than required, after a fid has been obtained. Just move the version check earlier.

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

scsi: ibmvfc: Store vhost pointer during subcrq allocation

Currently the back pointer from a queue to the vhost adapter isn't set until after subcrq interrupt registration. The value is available when a queue is first allocated and can/should be also set for primary and async queues as well as subcrqs.

This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS interrupt controller where a pending subcrq interrupt from the previous kernel can be replayed immediately upon IRQ registration resulting in dereference of a garbage backpointer in ibmvfcinterruptscsi().

Kernel attempted to read user page (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfcinterruptscsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] handleirqeventpercpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] handleirqeventpercpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handleirqevent+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handlefasteoiirq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generichandleirq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] doirq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] doIRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] doIRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replaysoftinterrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] archlocalirqrestore+0x108/0x170 [c000000014623240] [c000000008eb1008] rawspinunlockirqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] setupirq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] requestthreadedirq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfcregisterscsichannel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfcinitsubcrqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfcresetcrq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfcinitcrq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfcprobe+0x2a4/0x530 [ibmvfc]

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

btrfs: fix hang during unmount when block group reclaim task is running

When we start an unmount, at closectree(), if we have the reclaim task running and in the middle of a data block group relocation, we can trigger a deadlock when stopping an async reclaim task, producing a trace like the following:

[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000 [629724.499760] Workqueue: eventsunbound btrfsasyncreclaimmetadataspace [btrfs] [629724.501267] Call Trace: [629724.501759] <TASK> [629724.502174] schedule+0x3cb/0xed0 [629724.502842] schedule+0x4e/0xb0 [629724.503447] btrfswaitondelayediputs+0x7c/0xc0 [btrfs] [629724.504534] ? preparetowaitexclusive+0xc0/0xc0 [629724.505442] flushspace+0x423/0x630 [btrfs] [629724.506296] ? rcureadunlocktracespecial+0x20/0x50 [629724.507259] ? lockrelease+0x220/0x4a0 [629724.507932] ? btrfsgetallocprofile+0xb3/0x290 [btrfs] [629724.508940] ? dorawspinunlock+0x4b/0xa0 [629724.509688] btrfsasyncreclaimmetadataspace+0x139/0x320 [btrfs] [629724.510922] processonework+0x252/0x5a0 [629724.511694] ? processonework+0x5a0/0x5a0 [629724.512508] workerthread+0x52/0x3b0 [629724.513220] ? processonework+0x5a0/0x5a0 [629724.514021] kthread+0xf2/0x120 [629724.514627] ? kthreadcompleteandexit+0x20/0x20 [629724.515526] retfromfork+0x22/0x30 [629724.516236] </TASK> [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000 [629724.518269] Call Trace: [629724.518746] <TASK> [629724.519160] schedule+0x3cb/0xed0 [629724.519835] schedule+0x4e/0xb0 [629724.520467] scheduletimeout+0xed/0x130 [629724.521221] ? lockrelease+0x220/0x4a0 [629724.521946] ? lockacquired+0x19c/0x420 [629724.522662] ? tracehardirqson+0x1b/0xe0 [629724.523411] waitforcommon+0xaf/0x1f0 [629724.524189] ? usleeprangestate+0xb0/0xb0 [629724.524997] flushwork+0x26d/0x530 [629724.525698] ? flushworkqueuepreppwqs+0x140/0x140 [629724.526580] ? lockacquire+0x1a0/0x310 [629724.527324] cancelworktimer+0x137/0x1c0 [629724.528190] closectree+0xfd/0x531 [btrfs] [629724.529000] ? evictinodes+0x166/0x1c0 [629724.529510] genericshutdownsuper+0x74/0x120 [629724.530103] killanonsuper+0x14/0x30 [629724.530611] btrfskillsuper+0x12/0x20 [btrfs] [629724.531246] deactivatelockedsuper+0x31/0xa0 [629724.531817] cleanupmnt+0x147/0x1c0 [629724.532319] taskworkrun+0x5c/0xa0 [629724.532984] exittousermodeprepare+0x1a6/0x1b0 [629724.533598] syscallexittousermode+0x16/0x40 [629724.534200] dosyscall64+0x48/0x90 [629724.534667] entrySYSCALL64afterhwframe+0x44/0xae [629724.535318] RIP: 0033:0x7fa2b90437a7 [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIGRAX: 00000000000000a6 [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7 [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0 [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200 [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000 [629724.541796] </TASK>

This happens because:

1) Before entering closectree() we have the async block group reclaim task running and relocating a data block group;

2) There's an async metadata (or data) space reclaim task running;

3) We enter closectree() and park the cleaner kthread;

4) The async space reclaim task is at flushspace() and runs all the existing delayed iputs;

5) Before the async space reclaim task calls btrfswaitondelayediputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replacefileextents() (called when COWing leaves that have file extent items pointing to relocated data exten ---truncated---

filemap: Handle sibling entries in filemapgetreadbatch()

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

bpf: Fix requestsock leak in sk lookup helpers

A customer reported a requestsocket leak in a Calico cloud environment. We found that a BPF program was doing a socket lookup with takes a refcnt on the socket and that it was finding the requestsocket but returning the parent LISTEN socket via sktofullsk() without decrementing the child request socket 1st, resulting in requestsock slab object leak. This patch retains the existing behaviour of returning full socks to the caller but it also decrements the child requestsocket if one is present before doing so to prevent the leak.

Thanks to Curtis Taylor for all the help in diagnosing and testing this. And thanks to Antoine Tenart for the reproducer and patch input.

v2 of this patch contains, refactor as per Daniel Borkmann's suggestions to validate RCU flags on the listen socket so that it balances with bpfskrelease() and update comments as per Martin KaFai Lau's suggestion. One small change to Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra instruction.

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

drm/msm/mdp4: Fix refcount leak in mdp4modesetinitintf

ofgraphgetremotenode() returns remote device node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

Patchwork: https://patchwork.freedesktop.org/patch/488473/

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

erspan: do not assume transport header is always set

Rewrite tests in ip6erspantunnelxmit() and erspanfbxmit() to not assume transport header is set.

syzbot reported:

WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skbtransportheader include/linux/skbuff.h:2911 [inline] WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspantunnelxmit+0x15af/0x2eb0 net/ipv6/ip6gre.c:963 Modules linked in: CPU: 0 PID: 1350 Comm: aoetx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:skbtransportheader include/linux/skbuff.h:2911 [inline] RIP: 0010:ip6erspantunnelxmit+0x15af/0x2eb0 net/ipv6/ip6gre.c:963 Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00 RSP: 0018:ffffc90005daf910 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003 RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40 R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000 FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0 Call Trace: <TASK> netdevstartxmit include/linux/netdevice.h:4805 [inline] netdevstartxmit include/linux/netdevice.h:4819 [inline] xmitone net/core/dev.c:3588 [inline] devhardstartxmit+0x188/0x880 net/core/dev.c:3604 schdirectxmit+0x19f/0xbe0 net/sched/schgeneric.c:342 devxmitskb net/core/dev.c:3815 [inline] devqueuexmit+0x14a1/0x3900 net/core/dev.c:4219 devqueuexmit include/linux/netdevice.h:2994 [inline] tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63 kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229 kthread+0x2e9/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:302 </TASK>

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

net: phy: at803x: fix NULL pointer dereference on AR9331 PHY

Latest kernel will explode on the PHY interrupt config, since it depends now on allocated priv. So, run probe to allocate priv to fix it.

ar9331switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13) CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34 ... Call Trace: [<8050e8a8>] at803xconfigintr+0x5c/0xd0 [<80504b34>] phyrequestinterrupt+0xa8/0xd0 [<8050289c>] phylinkbringupphy+0x2d8/0x3ac [<80502b68>] phylinkfwnodephyconnect+0x118/0x130 [<8074d8ec>] dsaslavecreate+0x270/0x420 [<80743b04>] dsaportsetup+0x12c/0x148 [<8074580c>] dsaregisterswitch+0xaf0/0xcc0 [<80511344>] ar9331swprobe+0x370/0x388 [<8050cb78>] mdioprobe+0x44/0x70 [<804df300>] reallyprobe+0x200/0x424 [<804df7b4>] driverprobedevice+0x290/0x298 [<804df810>] driverprobedevice+0x54/0xe4 [<804dfd50>] deviceattachdriver+0xe4/0x130 [<804dcb00>] busforeachdrv+0xb4/0xd8 [<804dfac4>] deviceattach+0x104/0x1a4 [<804ddd24>] busprobedevice+0x48/0xc4 [<804deb44>] deferredprobeworkfunc+0xf0/0x10c [<800a0ffc>] processonework+0x314/0x4d4 [<800a17fc>] workerthread+0x2a4/0x354 [<800a9a54>] kthread+0x134/0x13c [<8006306c>] retfromkernelthread+0x14/0x1c

Same Issue would affect some other PHYs (QCA8081, QCA9561), so fix it too.

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

afs: Fix dynamic root getattr

The recent patch to make afsgetattr consult the server didn't account for the pseudo-inodes employed by the dynamic root-type afs superblock not having a volume or a server to access, and thus an oops occurs if such a directory is stat'd.

Fix this by checking to see if the vnode->volume pointer actually points anywhere before following it in afsgetattr().

This can be tested by stat'ing a directory in /afs. It may be sufficient just to do "ls /afs" and the oops looks something like:

BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:afsgetattr+0x8b/0x14b ... Call Trace: <TASK> vfsstatx+0x79/0xf5 vfsfstatat+0x49/0x62