The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ALSA: hda: intel-sdw-acpi: harden detection of controller

The existing code currently sets a pointer to an ACPI handle before checking that it's actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already.

This patch changes the logic so that the information provided to the caller is set when a controller is found.(CVE-2021-46926)

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

uiohvgeneric: Fix another memory leak in error handling paths

Memory allocated by 'vmbusallocring()' at the beginning of the probe function is never freed in the error handling path.

Add the missing 'vmbusfreering()' call.

Note that it is already freed in the .remove function.(CVE-2021-47070)

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:

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: mwifiex: Fix oob check condition in mwifiexprocessrx_packet

Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers.(CVE-2023-52525)

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:

mm/damon/vaddr-test: fix memory leak in damondotestapplythree_regions()

When CONFIGDAMONVADDRKUNITTEST=y and making CONFIGDEBUGKMEMLEAK=y and CONFIGDEBUGKMEMLEAKAUTOSCAN=y, the below memory leak is detected.

Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary variables"), the damondestroyctx() is removed, but still call damonnewtarget() and damonnewregion(), the damonregion which is allocated by kmemcachealloc() in damonnewregion() and the damontarget which is allocated by kmalloc in damonnewtarget() are not freed. And the damonregion which is allocated in damonnewregion() in damonset_regions() is also not freed.

So use damondestroytarget to free all the damonregions and damontarget.

unreferenced object 0xffff888107c9a940 (size 64):
  comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
    60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff  `...............
  backtrace:
    [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
    [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
    [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
    [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
    [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
    [<ffffffff81237cf6>] kthread+0x2b6/0x380
    [<ffffffff81097add>] ret_from_fork+0x2d/0x70
    [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079cc740 (size 56):
  comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
  hex dump (first 32 bytes):
    05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
    6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
  backtrace:
    [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
    [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
    [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
    [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
    [<ffffffff81237cf6>] kthread+0x2b6/0x380
    [<ffffffff81097add>] ret_from_fork+0x2d/0x70
    [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9ac40 (size 64):
  comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
    a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff  ........x.v.....
  backtrace:
    [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
    [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
    [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
    [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
    [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
    [<ffffffff81237cf6>] kthread+0x2b6/0x380
    [<ffffffff81097add>] ret_from_fork+0x2d/0x70
    [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079ccc80 (size 56):
  comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
  hex dump (first 32 bytes):
    05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
    6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
  backtrace:
    [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
    [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
    [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
    [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
    [<ffffffff81237cf6>] kthread+0x2b6/0x380
    [<ffffffff81097add>] ret_from_fork+0x2d/0x70
    [<ffff

---truncated---(CVE-2023-52560)

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

arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved

Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader).

It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y.(CVE-2023-52561)

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:

x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race

The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an enclave and set secs.epcpage to NULL. The SECS page is used for EAUG and ELDU in the SGX page fault handler. However, the NULL check for secs.epcpage is only done for ELDU, not EAUG before being used.

Fix this by doing the same NULL check and reloading of the SECS page as needed for both EAUG and ELDU.

The SECS page holds global enclave metadata. It can only be reclaimed when there are no other enclave pages remaining. At that point, virtually nothing can be done with the enclave until the SECS page is paged back in.

An enclave can not run nor generate page faults without a resident SECS page. But it is still possible for a #PF for a non-SECS page to race with paging out the SECS page: when the last resident non-SECS page A triggers a #PF in a non-resident page B, and then page A and the SECS both are paged out before the #PF on B is handled.

Hitting this bug requires that race triggered with a #PF for EAUG. Following is a trace when it happens.

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:sgxencleaugpage+0xc7/0x210 Call Trace: ? _kmemcacheallocnode+0x16a/0x440 ? xaload+0x6e/0xa0 sgxvmafault+0x119/0x230 _dofault+0x36/0x140 dofault+0x12f/0x400 _handlemmfault+0x728/0x1110 handlemmfault+0x105/0x310 douseraddrfault+0x1ee/0x750 ? _thiscpupreemptcheck+0x13/0x20 excpagefault+0x76/0x180 asmexcpagefault+0x27/0x30(CVE-2023-52568)

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

net: rds: Fix possible NULL-pointer dereference

In rdsrdmacmeventhandlercmn() check, if conn pointer exists before dereferencing it as rdmasetservicetype() argument

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52573)

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

dccp: fix dccpv4err()/dccpv6err() again

dh->dccphx is the 9th byte (offset 8) in "struct dccphdr", not in the "byte 7" as Jann claimed.

We need to make sure the ICMP messages are big enough, using more standard ways (no more assumptions).

syzbot reported: BUG: KMSAN: uninit-value in pskbmaypullreason include/linux/skbuff.h:2667 [inline] BUG: KMSAN: uninit-value in pskbmaypull include/linux/skbuff.h:2681 [inline] BUG: KMSAN: uninit-value in dccpv6err+0x426/0x1aa0 net/dccp/ipv6.c:94 pskbmaypullreason include/linux/skbuff.h:2667 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] dccpv6err+0x426/0x1aa0 net/dccp/ipv6.c:94 icmpv6notify+0x4c7/0x880 net/ipv6/icmp.c:867 icmpv6rcv+0x19d5/0x30d0 ip6protocoldeliverrcu+0xda6/0x2a60 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:304 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:468 [inline] ip6rcvfinish+0x5db/0x870 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:304 [inline] ipv6rcv+0xda/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbonecore net/core/dev.c:5523 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5637 netifreceiveskbinternal net/core/dev.c:5723 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5782 tunrxbatched+0x83b/0x920 tungetuser+0x564c/0x6940 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:1985 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x8ef/0x15c0 fs/readwrite.c:584 ksyswrite+0x20f/0x4c0 fs/readwrite.c:637 _dosyswrite fs/readwrite.c:649 [inline] _sesyswrite fs/readwrite.c:646 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:646 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

Uninit was created at: slabpostallochook+0x12f/0xb70 mm/slab.h:767 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x577/0xa80 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:559 _allocskb+0x318/0x740 net/core/skbuff.c:650 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6313 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2795 tunallocskb drivers/net/tun.c:1531 [inline] tungetuser+0x23cf/0x6940 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:1985 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x8ef/0x15c0 fs/readwrite.c:584 ksyswrite+0x20f/0x4c0 fs/readwrite.c:637 _dosyswrite fs/readwrite.c:649 [inline] _sesyswrite fs/readwrite.c:646 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:646 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023(CVE-2023-52577)

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)

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

ext4: regenerate buddy after block freeing failed if under fc replay

This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mbregeneratebuddy()") and reintroduces mbregeneratebuddy(). Based on code in mbfreeblocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case.(CVE-2024-26601)