The Linux Kernel, the operating system core itself.

Security Fix(es):

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

i2c: img-scb: fix reference leak when pmruntimeget_sync fails

The PM reference count is not expected to be incremented on return in functions imgi2cxfer and imgi2cinit.

However, pmruntimeget_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pmruntimeresumeandget to keep usage counter balanced.(CVE-2020-36783)

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

kyber: fix out of bounds access when preempted

_blkmqschedbiomerge() gets the ctx and hctx for the current CPU and passes the hctx to ->biomerge(). kyberbiomerge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blkmqgetctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->indexhw[hctx->type] > hctx->nr_ctx).

This manifested as this UBSAN array index out of bounds error reported by Jakub:

UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dumpstack+0xa4/0xe5 ubsanepilogue+0x5/0x40 _ubsanhandleoutofbounds.cold.13+0x2a/0x34 queuedspinlockslowpath+0x476/0x480 dorawspinlock+0x1c2/0x1d0 kyberbiomerge+0x112/0x180 blkmqsubmitbio+0x1f5/0x1100 submitbionoacct+0x7b0/0x870 submitbio+0xc2/0x3a0 btrfsmapbio+0x4f0/0x9d0 btrfssubmitdatabio+0x24e/0x310 submitonebio+0x7f/0xb0 submitextentpage+0xc4/0x440 _extentwritepageio+0x2b8/0x5e0 _extentwritepage+0x28d/0x6e0 extentwritecachepages+0x4d7/0x7a0 extentwritepages+0xa2/0x110 dowritepages+0x8f/0x180 _writebacksingleinode+0x99/0x7f0 writebacksbinodes+0x34e/0x790 _writebackinodeswb+0x9e/0x120 wbwriteback+0x4d2/0x660 wbworkfn+0x64d/0xa10 processonework+0x53a/0xa80 workerthread+0x69/0x5b0 kthread+0x20b/0x240 retfrom_fork+0x1f/0x30

Only Kyber uses the hctx, so fix it by passing the requestqueue to ->biomerge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.(CVE-2021-46984)

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

bus: qcom: Put child node before return

Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro foreachavailablechildof_node() and should be decremented manually if the loop is broken in loop body.(CVE-2021-47054)

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

crypto: qat - ADFSTATUSPFRUNNING should be set after adfdev_init

ADFSTATUSPFRUNNING is (only) used and checked by adfvf2pfshutdown() before calling adfiovputmsg()->mutexlock(vf2pflock), however the vf2pflock is initialized in adfdevinit(), which can fail and when it fail, the vf2pflock is either not initialized or destroyed, a subsequent use of vf2pflock will cause issue. To fix this issue, only set this flag if adfdevinit() returns 0.

[ 7.178404] BUG: KASAN: user-memory-access in _mutexlock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutexlock+0xc9/0xd0 [ 7.183257] adfiovputmsg+0x118/0x1a0 [intelqat] [ 7.183541] adfvf2pfshutdown+0x4d/0x7b [intelqat] [ 7.183834] adfdevshutdown+0x172/0x2b0 [intelqat] [ 7.184127] adfprobe+0x5e9/0x600 qatdh895xccvf

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

KVM: Stop looking for coalesced MMIO zones if the bus is destroyed

Abort the walk of coalesced MMIO zones if kvmiobusunregisterdev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregisterdev() destroys all devices _except the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted.

Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement.(CVE-2021-47060)

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

KVM: Destroy I/O bus devices on unregister failure after sync'ing SRCU

If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid.(CVE-2021-47061)

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

drm: bridge/panel: Cleanup connector on bridge detach

If we don't call drmconnectorcleanup() manually in panelbridgedetach(), the connector will be cleaned up with the other DRM objects in the call to drmmodeconfigcleanup(). However, since our drmconnector is devm-allocated, by the time drmmodeconfig_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions.

v2: Cleanup connector only if it was created

v3: Add FIXME

v4: (Use connector->dev) directly in if() block(CVE-2021-47063)

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

uiohvgeneric: Fix a memory leak in error handling paths

If 'vmbusestablishgpadl()' fails, the (recv|send)gpadl will not be updated and 'hvuio_cleanup()' in the error handling path will not be able to free the corresponding buffer.

In such a case, we need to free the buffer explicitly.(CVE-2021-47071)

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

nvme-loop: fix memory leak in nvmeloopcreate_ctrl()

When creating loop ctrl in nvmeloopcreatectrl(), if nvmeinit_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label.(CVE-2021-47074)

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

scsi: qedf: Add pointer checks in qedfupdatelink_speed()

The following trace was observed:

[ 14.042059] Call Trace: [ 14.042061] <IRQ> [ 14.042068] qedflinkupdate+0x144/0x1f0 [qedf] [ 14.042117] qedlinkupdate+0x5c/0x80 [qed] [ 14.042135] qedmcphandlelinkchange+0x2d2/0x410 [qed] [ 14.042155] ? qedsetptt+0x70/0x80 [qed] [ 14.042170] ? qedsetptt+0x70/0x80 [qed] [ 14.042186] ? qedrd+0x13/0x40 [qed] [ 14.042205] qedmcphandleevents+0x437/0x690 [qed] [ 14.042221] ? qedsetptt+0x70/0x80 [qed] [ 14.042239] qedintspdpc+0x3a6/0x3e0 [qed] [ 14.042245] taskletactioncommon.isra.14+0x5a/0x100 [ 14.042250] _dosoftirq+0xe4/0x2f8 [ 14.042253] irqexit+0xf7/0x100 [ 14.042255] doIRQ+0x7f/0xd0 [ 14.042257] commoninterrupt+0xf/0xf [ 14.042259] </IRQ>

API qedflinkupdate() is getting called from QED but by that time shostdata is not initialised. This results in a NULL pointer dereference when we try to dereference shostdata while updating supported_speeds.

Add a NULL pointer check before dereferencing shost_data.(CVE-2021-47077)

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

RDMA/rxe: Clear all QP fields if creation failed

rxeqpdocleanup() relies on valid pointer values in QP for the properly created ones, but in case rxeqpfrominit() failed it was filled with garbage and caused tot the following error.

refcountt: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcountwarnsaturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcountwarnsaturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: refcountsubandtest include/linux/refcount.h:283 [inline] _refcountdecandtest include/linux/refcount.h:315 [inline] refcountdecandtest include/linux/refcount.h:333 [inline] krefput include/linux/kref.h:64 [inline] rxeqpdocleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxeqp.c:805 executeinprocesscontext+0x37/0x150 kernel/workqueue.c:3327 rxeelemrelease+0x9f/0x180 drivers/infiniband/sw/rxe/rxepool.c:391 krefput include/linux/kref.h:65 [inline] rxecreateqp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxeverbs.c:425 ibcreateqp drivers/infiniband/core/corepriv.h:331 [inline] ibcreatenamedqp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ibcreateqp include/rdma/ibverbs.h:3644 [inline] createmadqp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ibmadportopen drivers/infiniband/core/mad.c:3001 [inline] ibmadinitdevice+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 addclientcontext+0x405/0x5e0 drivers/infiniband/core/device.c:717 enabledeviceandget+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ibregisterdevice drivers/infiniband/core/device.c:1413 [inline] ibregisterdevice+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxeregisterdevice+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxeverbs.c:1147 rxeadd+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxenetadd+0x8c/0xe0 drivers/infiniband/sw/rxe/rxenet.c:503 rxenewlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxenewlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldevnewlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdmanlrcvmsg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdmanlrcvskb drivers/infiniband/core/netlink.c:239 [inline] rdmanlrcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlinkunicastkernel net/netlink/afnetlink.c:1312 [inline] netlinkunicast+0x533/0x7d0 net/netlink/afnetlink.c:1338 netlinksendmsg+0x856/0xd90 net/netlink/afnetlink.c:1927 socksendmsgnosec net/socket.c:654 [inline] socksendmsg+0xcf/0x120 net/socket.c:674 _syssendmsg+0x6e8/0x810 net/socket.c:2350 _syssendmsg+0xf3/0x170 net/socket.c:2404 _syssendmsg+0xe5/0x1b0 net/socket.c:2433 dosyscall64+0x3a/0xb0 arch/x86/entry/common.c:47 entrySYSCALL64afterhwframe+0 ---truncated---(CVE-2021-47078)

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

asix: fix uninit-value in asixmdioread()

asixreadcmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized.

Fail log: BUG: KMSAN: uninit-value in asixcheckhostenable drivers/net/usb/asixcommon.c:82 [inline] BUG: KMSAN: uninit-value in asixcheckhostenable drivers/net/usb/asixcommon.c:82 [inline] drivers/net/usb/asixcommon.c:497 BUG: KMSAN: uninit-value in asixmdioread+0x3c1/0xb00 drivers/net/usb/asixcommon.c:497 drivers/net/usb/asixcommon.c:497 asixcheckhostenable drivers/net/usb/asixcommon.c:82 [inline] asixcheckhostenable drivers/net/usb/asixcommon.c:82 [inline] drivers/net/usb/asixcommon.c:497 asixmdioread+0x3c1/0xb00 drivers/net/usb/asixcommon.c:497 drivers/net/usb/asixcommon.c:497(CVE-2021-47101)

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

net/tls: Fix use-after-free after the TLS device goes down and up

When a netdev with active TLS offload goes down, tlsdevicedown is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context.

This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode.

On the TX side tlsswfallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets.

The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tlsdevresync after tlsdevdel).

A new flag called TLSRXDEVDEGRADED is added to indicate the fallback mode. It's used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resyncasync, which is allocated and freed by the driver).(CVE-2021-47131)

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

drm/amdgpu: Fix a use-after-free

looks like we forget to set ttm->sg to NULL. Hit panic below

[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUGPAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sgfreetable+0x17/0x20 [ 1235.995667] amdgputtmbackendunbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgputtmbackenddestroy+0x29/0x130 [amdgpu] [ 1236.008464] ttmttdestroy+0x1e/0x30 [ttm] [ 1236.013066] ttmbocleanupmemtypeuse+0x51/0xa0 [ttm] [ 1236.018783] ttmborelease+0x262/0xa50 [ttm] [ 1236.023547] ttmboput+0x82/0xd0 [ttm] [ 1236.027766] amdgpubounref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpuamdkfdgpuvmallocmemoryofgpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfdioctlallocmemoryofgpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 amdgpu

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

net/smc: remove device from smcddevlist after failed device_add()

If the deviceadd() for a smcddev fails, there's no cleanup step that rolls back the earlier list_add(). The device subsequently gets freed, and we end up with a corrupted list.

Add some error handling that removes the device from the list.(CVE-2021-47143)

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

drm/amd/amdgpu: fix refcount leak

[Why] the gem object rfb->base.obj[0] is get according to numplanes in amdgpufbcreate, but is not put according to num_planes

[How] put rfb->base.obj[0] in amdgpufbdevdestroy according to num_planes(CVE-2021-47144)

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

btrfs: do not BUGON in linktofixupdir

While doing error injection testing I got the following panic

kernel BUG at fs/btrfs/tree-log.c:1862! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:linktofixupdir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0 RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001 R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0 Call Trace: replayonebuffer+0x409/0x470 ? btreereadextentbufferpages+0xd0/0x110 walkuplogtree+0x157/0x1e0 walklogtree+0xa6/0x1d0 btrfsrecoverlogtrees+0x1da/0x360 ? replayoneextent+0x7b0/0x7b0 openctree+0x1486/0x1720 btrfsmountroot.cold+0x12/0xea ? _kmalloctrackcaller+0x12f/0x240 legacygettree+0x24/0x40 vfsgettree+0x22/0xb0 vfskernmount.part.0+0x71/0xb0 btrfsmount+0x10d/0x380 ? vfsparsefsstring+0x4d/0x90 legacygettree+0x24/0x40 vfsgettree+0x22/0xb0 pathmount+0x433/0xa10 _x64sysmount+0xe3/0x120 dosyscall64+0x3d/0x80 entrySYSCALL64after_hwframe+0x44/0xae

We can get -EIO or any number of legitimate errors from btrfssearchslot(), panicing here is not the appropriate response. The error path for this code handles errors properly, simply return the error.(CVE-2021-47145)

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

mld: fix panic in mld_newpack()

mldnewpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom size is too large, a kernel panic could occur in skbput().

Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B

ip netns exec A ip link set lo up
ip netns exec A ip link set veth0 up
ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0
ip netns exec B ip link set lo up
ip netns exec B ip link set veth1 up
ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1
for i in {1..99}
do
    let A=$i-1
    ip netns exec A ip link add ip6gre$i type ip6gre \
local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100
    ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i
    ip netns exec A ip link set ip6gre$i up

    ip netns exec B ip link add ip6gre$i type ip6gre \
local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100
    ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i
    ip netns exec B ip link set ip6gre$i up
done

Splat looks like: kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6addrconf addrconfdadwork RIP: 0010:skbpanic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP: 0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000 RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028 R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000) GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ip6mchdr.isra.26.constprop.46+0x12a/0x600 ? ip6mchdr.isra.26.constprop.46+0x12a/0x600 skbput.cold.104+0x22/0x22 ip6mchdr.isra.26.constprop.46+0x12a/0x600 ? rcureadlockschedheld+0x91/0xc0 mldnewpack+0x398/0x8f0 ? ip6mchdr.isra.26.constprop.46+0x600/0x600 ? lockcontended+0xc40/0xc40 addgrhead.isra.33+0x280/0x380 addgrec+0x5ca/0xff0 ? mldsendpack+0xf40/0xf40 ? lockdowngrade+0x690/0x690 mldsendinitialcr.part.34+0xb9/0x180 ipv6mcdadcomplete+0x15d/0x1b0 addrconfdadcompleted+0x8d2/0xbb0 ? lockdowngrade+0x690/0x690 ? addrconfrstimer+0x660/0x660 ? addrconfdadwork+0x73c/0x10e0 addrconfdad_work+0x73c/0x10e0

Allowing high order page allocation could fix this problem.(CVE-2021-47146)

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

i2c: i801: Don't generate an interrupt on bus reset

Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access.

This condition was reproduced several times by syzbot: https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79

So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction.(CVE-2021-47153)

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

net: dsa: fix a crash if ->getssetcount() fails

If ds->ops->getssetcount() fails then it "count" is a negative error code such as -EOPNOTSUPP. Because "i" is an unsigned int, the negative error code is type promoted to a very high value and the loop will corrupt memory until the system crashes.

Fix this by checking for error codes and changing the type of "i" to just int.(CVE-2021-47159)

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

net: dsa: mt7530: fix VLAN traffic leaks

PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but was not reset when it is disabled, which may cause traffic leaks:

ip link add br0 type bridge vlan_filtering 1
ip link add br1 type bridge vlan_filtering 1
ip link set swp0 master br0
ip link set swp1 master br1
ip link set br0 type bridge vlan_filtering 0
ip link set br1 type bridge vlan_filtering 0
# traffic in br0 and br1 will start leaking to each other

As portbridge{add,del} have set up PCRMATRIX properly, remove the PCRMATRIX write from mt7530portsetvlanaware.(CVE-2021-47160)

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

spi: spi-fsl-dspi: Fix a resource leak in an error handling path

'dspirequestdma()' should be undone by a 'dspireleasedma()' call in the error handling path of the probe function, as already done in the remove function(CVE-2021-47161)

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

tipc: skb_linearize the head skb when reassembling msgs

It's not a good idea to append the frag skb to a skb's fraglist if the fraglist already has skbs from elsewhere, such as this skb was created by pskbcopy() where the fraglist was cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs.

However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once.

The same thing happens with a skb updated by pskbmaypull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices:

[] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skbclone+0x4d/0xb0 [] macvlanbroadcast+0xd8/0x160 [macvlan] [] macvlanprocessbroadcast+0x148/0x150 [macvlan] [] processonework+0x1a7/0x360 [] worker_thread+0x30/0x390

[] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] checkheapobject+0xd3/0x100 [] _checkobjectsize+0xff/0x16b [] simplecopytoiter+0x1c/0x30 [] _skbdatagramiter+0x7d/0x310 [] _skbdatagramiter+0x2a5/0x310 [] skbcopydatagramiter+0x3b/0x90 [] tipcrecvmsg+0x14a/0x3a0 [tipc] [] sysrecvmsg+0x91/0x150 [] _sysrecvmsg+0x7b/0xc0

[] kernel BUG at mm/slub.c:305! [] Call Trace: [] <IRQ> [] kmemcachefree+0x3ff/0x400 [] _netifreceiveskbcore+0x12c/0xc40 [] ? kmemcachealloc+0x12e/0x270 [] netifreceiveskbinternal+0x3d/0xb0 [] ? getrxpageinfo+0x8e/0xa0 [be2net] [] bepoll+0x6ef/0xd00 [be2net] [] ? irqexit+0x4f/0x100 [] netrxaction+0x149/0x3b0

...

This patch is to fix it by linearizing the head skb if it has fraglist set in tipcbufappend(). Note that we choose to do this before calling skbunshare(), as _skblinearize() will avoid skbcopy(). Also, we can not just drop the fraglist either as the early time.(CVE-2021-47162)

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

tipc: wait and exit until all work queues are done

On some host, a crash could be triggered simply by repeating these commands several times:

# modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc

[] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? processonework+0x1a7/0x360 [] ? workerthread+0x30/0x390 [] ? createworker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthreadflushworkfn+0x10/0x10 [] ? retfrom_fork+0x35/0x40

When removing the TIPC module, the UDP tunnel sock will be delayed to release in a work queue as sockrelease() can't be done in rtnllock(). If the work queue is schedule to run after the TIPC module is removed, kernel will crash as the work queue function cleanup_beareri() code no longer exists when trying to invoke it.

To fix it, this patch introduce a member wqcount in tipcnet to track the numbers of work queues in schedule, and wait and exit until all work queues are done in tipcexitnet().(CVE-2021-47163)

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

NFS: Fix an Oopsable condition in _nfspageioaddrequest()

Ensure that nfspageioerrorcleanup() resets the mirror array contents, so that the structure reflects the fact that it is now empty. Also change the test in nfspageiodoaddrequest() to be more robust by checking whether or not the list is empty rather than relying on the value of pgcount.(CVE-2021-47167)

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

USB: usbfs: Don't WARN about excessively large memory allocations

Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly.

In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers.

To prevent the MM subsystem from complaining about these bad allocation requests, add the _GFPNOWARN flag to the kmalloc calls for these buffers.(CVE-2021-47170)

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

net: usb: fix memory leak in smsc75xx_bind

Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation.

backtrace: [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline] [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline] [<ffffffff84245b62>] smsc75xxbind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [<ffffffff82b5b2e6>] usbnetprobe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728(CVE-2021-47171)

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

misc/uss720: fix memory leak in uss720_probe

uss720probe forgets to decrease the refcount of usbdev in uss720probe. Fix this by decreasing the refcount of usbdev by usbputdev.

BUG: memory leak unreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline] [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline] [<ffffffff82b8e822>] usballocdev+0x32/0x450 drivers/usb/core/usb.c:582 [<ffffffff82b98441>] hubportconnect drivers/usb/core/hub.c:5129 [inline] [<ffffffff82b98441>] hubportconnectchange drivers/usb/core/hub.c:5363 [inline] [<ffffffff82b98441>] portevent drivers/usb/core/hub.c:5509 [inline] [<ffffffff82b98441>] hubevent+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [<ffffffff81259229>] processonework+0x2c9/0x600 kernel/workqueue.c:2275 [<ffffffff81259b19>] workerthread+0x59/0x5d0 kernel/workqueue.c:2421 [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292 [<ffffffff8100227f>] retfromfork+0x1f/0x30 arch/x86/entry/entry_64.S:294(CVE-2021-47173)

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

NFC: nci: fix memory leak in nciallocatedevice

nfcmrvldisconnect fails to free the hcidev field in struct ncidev. Fix this by freeing hcidev in ncifreedevice.

BUG: memory leak unreferenced object 0xffff888111ea6800 (size 1024): comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>] ncihciallocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nciallocatedevice net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nciallocatedevice+0x10b/0x160 net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvlnciregisterdev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvlprobe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usbprobeinterface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] reallyprobe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driverprobedevice+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>] _deviceattachdriver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] busforeachdrv+0xb7/0x100 drivers/base/bus.c:431 [<00000000f8e13372>] _deviceattach+0x122/0x250 drivers/base/dd.c:914 [<000000009cf68860>] busprobedevice+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>] deviceadd+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usbsetconfiguration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<00000000ca036872>] usbgenericdriverprobe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usbprobedevice+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000bc632c92>] reallyprobe+0x159/0x4a0 drivers/base/dd.c:554(CVE-2021-47180)

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

EDAC/thunderx: Fix possible out-of-bounds string access

Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat():

drivers/edac/thunderxedac.c: In function 'thunderxocxcomthreadedisr': drivers/edac/thunderxedac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCXMESSAGESIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCXMESSAGESIZE); ... 1150 | strncat(msg, other, OCXMESSAGESIZE);

...

Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer.

Change it to strlcat().

bp: Trim compiler output, fixup commit message.

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

Input: powermate - fix use-after-free in powermateconfigcomplete

syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug.

Use usbkillurb() on pm->config to cancel any in-progress requests upon device disconnection.

[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475)

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

scsi: pm80xx: Avoid leaking tags when processing OPCINBSETCONTROLLERCONFIG command

Tags allocated for OPCINBSETCONTROLLERCONFIG command need to be freed when we receive the response.(CVE-2023-52500)

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

nfc: nci: assert requested protocol is valid

The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones.(CVE-2023-52507)

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

ieee802154: ca8210: Fix a potential UAF in ca8210_probe

If ofclkaddprovider() fails in ca8210registerextclock(), it calls clkunregister() to release priv->clk and returns an error. However, the caller ca8210probe() then calls ca8210remove(), where priv->clk is freed again in ca8210unregisterextclock(). In this case, a use-after-free may happen in the second time we call clk_unregister().

Fix this by removing the first clkunregister(). Also, priv->clk could be an error code on failure of clkregisterfixedrate(). Use ISERRORNULL to catch this case in ca8210unregisterextclock().(CVE-2023-52510)

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

RDMA/srp: Do not call scsidone() from srpabort()

After scmdehaborthandler() has called the SCSI LLD ehaborthandler callback, it performs one of the following actions: * Call scsiqueueinsert(). * Call scsifinishcommand(). * Call scsiehscmdadd(). Hence, SCSI abort handlers must not call scsidone(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsidone() call from srpabort(). Keep the srpfree_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned.(CVE-2023-52515)

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

net: fix possible store tearing in neighperiodicwork()

While looking at a related syzbot report involving neighperiodicwork(), I found that I forgot to add an annotation when deleting an RCU protected item from a list.

Readers use rcudeference(*np), we need to use either rcuassignpointer() or WRITEONCE() on writer side to prevent store tearing.

I use rcuassignpointer() to have lockdep support, this was the choice made in neighflushdev().(CVE-2023-52522)

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

wifi: mac80211: fix potential key use-after-free

When ieee80211keylink() is called by ieee80211gtkrekeyadd() but returns 0 due to KRACK protection (identical key reinstall), ieee80211gtkrekeyadd() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211gtkrekey_add().(CVE-2023-52530)

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

nilfs2: fix potential use after free in nilfsgccachesubmitreaddata()

In nilfsgccachesubmitreaddata(), brelse(bh) is called to drop the reference count of bh when the call to nilfsdattranslate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page.

NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly.

konishi.ryusuke@gmail.com: NOTE added to the commit log

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

net: bridge: use DEVSTATSINC()

syzbot/KCSAN reported data-races in brhandleframe_finish() [1] This function can run from multiple cpus without mutual exclusion.

Adopt SMP safe DEVSTATSINC() to update dev->stats fields.

Handles updates to dev->stats.tx_dropped while we are at it.

[1] BUG: KCSAN: data-race in brhandleframefinish / brhandleframefinish

read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: brhandleframefinish+0xd4f/0xef0 net/bridge/brinput.c:189 brnfhookthresh+0x1ed/0x220 brnfpreroutingfinishipv6+0x50f/0x540 NFHOOK include/linux/netfilter.h:304 [inline] brnfpreroutingipv6+0x1e3/0x2a0 net/bridge/brnetfilteripv6.c:178 brnfprerouting+0x526/0xba0 net/bridge/brnetfilterhooks.c:508 nfhookentryhookfn include/linux/netfilter.h:144 [inline] nfhookbridgepre net/bridge/brinput.c:272 [inline] brhandleframe+0x4c9/0x940 net/bridge/brinput.c:417 _netifreceiveskbcore+0xa8a/0x21e0 net/core/dev.c:5417 _netifreceiveskbonecore net/core/dev.c:5521 [inline] _netifreceiveskb+0x57/0x1b0 net/core/dev.c:5637 processbacklog+0x21f/0x380 net/core/dev.c:5965 _napipoll+0x60/0x3b0 net/core/dev.c:6527 napipoll net/core/dev.c:6594 [inline] netrxaction+0x32b/0x750 net/core/dev.c:6727 _dosoftirq+0xc1/0x265 kernel/softirq.c:553 runksoftirqd+0x17/0x20 kernel/softirq.c:921 smpbootthreadfn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 retfromfork+0x48/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:304

read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0: brhandleframefinish+0xd4f/0xef0 net/bridge/brinput.c:189 brnfhookthresh+0x1ed/0x220 brnfpreroutingfinishipv6+0x50f/0x540 NFHOOK include/linux/netfilter.h:304 [inline] brnfpreroutingipv6+0x1e3/0x2a0 net/bridge/brnetfilteripv6.c:178 brnfprerouting+0x526/0xba0 net/bridge/brnetfilterhooks.c:508 nfhookentryhookfn include/linux/netfilter.h:144 [inline] nfhookbridgepre net/bridge/brinput.c:272 [inline] brhandleframe+0x4c9/0x940 net/bridge/brinput.c:417 _netifreceiveskbcore+0xa8a/0x21e0 net/core/dev.c:5417 _netifreceiveskbonecore net/core/dev.c:5521 [inline] _netifreceiveskb+0x57/0x1b0 net/core/dev.c:5637 processbacklog+0x21f/0x380 net/core/dev.c:5965 _napipoll+0x60/0x3b0 net/core/dev.c:6527 napipoll net/core/dev.c:6594 [inline] netrxaction+0x32b/0x750 net/core/dev.c:6727 _dosoftirq+0xc1/0x265 kernel/softirq.c:553 dosoftirq+0x5e/0x90 kernel/softirq.c:454 _localbhenableip+0x64/0x70 kernel/softirq.c:381 _rawspinunlockbh include/linux/spinlockapismp.h:167 [inline] _rawspinunlockbh+0x36/0x40 kernel/locking/spinlock.c:210 spinunlockbh include/linux/spinlock.h:396 [inline] batadvttlocalpurge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadvttpurge+0x2b/0x630 net/batman-adv/translation-table.c:3560 processonework kernel/workqueue.c:2630 [inline] processscheduledworks+0x5b8/0xa30 kernel/workqueue.c:2703 workerthread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 retfromfork+0x48/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:304

value changed: 0x00000000000d7190 -> 0x00000000000d7191

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0(CVE-2023-52578)

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

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.(CVE-2023-52583)

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

IB/ipoib: Fix mcast list locking

Releasing the priv->lock while iterating the priv->multicast_list in ipoib_mcast_join_task() opens a window for ipoib_mcast_dev_flush() to remove the items while in the middle of iteration. If the mcast is removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):

Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)
  spin_lock_irq(&priv->lock)       | __ipoib_ib_dev_flush(priv, ...)
  list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv->dev)
      &priv->multicast_list, list) |
    ipoib_mcast_join(dev, mcast)   |
      spin_unlock_irq(&priv->lock) |
                                   |   spin_lock_irqsave(&priv->lock, flags)
                                   |   list_for_each_entry_safe(mcast, tmcast,
                                   |                  &priv->multicast_list, list)
                                   |     list_del(&mcast->list);
                                   |     list_add_tail(&mcast->list, &remove_list)
                                   |   spin_unlock_irqrestore(&priv->lock, flags)
      spin_lock_irq(&priv->lock)   |
                                   |   ipoib_mcast_remove_list(&remove_list)

(Here, mcast is no longer on the | listforeachentrysafe(mcast, tmcast, priv->multicast_list and we keep | removelist, list) spinning on the remove_list of | >>> waitfor_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.)

Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups.

crash> bc 31

PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"

[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002
RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000
                              work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000
       &mcast->list
RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00
                                                     mcast
R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8
       dev                    priv (&priv->lock)     &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018

--- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoibmcastjointask+0x1b1 at ffffffffc0944ac1 [ibipoib] #6 [ff646f199a8c7e98] processonework+0x1a7 at ffffffff9bf10967

crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work

crash> list -hO ipoibdevpriv.multicast_list ff1c6a1a04dc8000 (empty)

crash> ipoibdevpriv.mcasttask.work.func,mcastmutex.owner.counter ff1c6a1a04dc8000 mcasttask.work.func = 0xffffffffc0944910 <ipoibmcastjointask>, mcast_mutex.owner.counter = 0xff1c69998efec000

crash> b 8

PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"

#3 [ff646f1980153d50] waitforcompletion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoibmcastremovelist+0x56 at ffffffffc0944dc6 [ibipoib] #5 [ff646f1980153de8] ipoibmcastdevflush+0x1a7 at ffffffffc09455a7 [ibipoib] #6 [ff646f1980153e58] _ipoibibdevflush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff ---truncated---(CVE-2023-52587)

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

wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9khtctxstatus()

Fix an array-index-out-of-bounds read in ath9khtctxstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTCMAXTXSTATUS. WARNON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case.

Found by a modified version of syzkaller.

UBSAN: array-index-out-of-bounds in htcdrvtxrx.c index 13 is out of range for type '_wmieventtxstatus [12]' Call Trace: ath9khtctxstatus ath9kwmieventtasklet taskletactioncommon _dosoftirq irqexitrxu sysvecapictimer_interrupt(CVE-2023-52594)

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

wifi: rt2x00: restart beacon queue when hardware reset

When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211restarthw().(CVE-2023-52595)

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

KVM: s390: fix setting of fpc register

kvmarchvcpuioctlset_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register.

This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with savefpuregs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space.

testfpctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space.

In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu.

Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values.

This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c.(CVE-2023-52597)

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

s390/ptrace: handle setting of fpc register correctly

If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register.

This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with savefpuregs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space.

testfpctl() restores the original user space fpc register value, however it will be discarded, when returning to user space.

In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process.

Fix this by saving fpu register contents with savefpuregs() before using testfpctl().(CVE-2023-52598)

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

ext4: avoid online resizing failures due to oversized flex bg

When we online resize an ext4 filesystem with a oversized flexbg_size,

 mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
 mount $dev $dir
 resize2fs $dev 16G

the following WARN_ON is triggered:

WARNING: CPU: 0 PID: 427 at mm/pagealloc.c:4402 allocpages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:allocpages+0x411/0x550 Call Trace: <TASK> _kmalloclargenode+0xa2/0x200 _kmalloc+0x16e/0x290 ext4resizefs+0x481/0xd80 _ext4ioctl+0x1616/0x1d90 ext4ioctl+0x12/0x20 _x64sys_ioctl+0xf0/0x150

dosyscall64+0x3b/0x90

This is because flexbgsize is too large and the size of the newgroupdata array to be allocated exceeds MAXORDER. Currently, the minimum value of MAXORDER is 8, the minimum value of PAGESIZE is 4096, the corresponding maximum number of groups that can be allocated is:

(PAGESIZE << MAXORDER) / sizeof(struct ext4newgroup_data) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAXRESIZEBG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed.(CVE-2023-52622)