OESA-2024-1356

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

KVM: x86/mmu: Don't advance iterator after restart due to yielding

After dropping mmulock in the TDP MMU, restart the iterator during tdpiter_next() and do not advance the iterator. Advancing the iterator results in skipping the top-level SPTE and all its children, which is fatal if any of the skipped SPTEs were not visited before yielding.

When zapping all SPTEs, i.e. when minlevel == rootlevel, restarting the iter and then invoking tdpiternext() is always fatal if the current gfn has as a valid SPTE, as advancing the iterator results in trystepside() skipping the current gfn, which wasn't visited before yielding.

Sprinkle WARNs on iter->yielded being true in various helpers that are often used in conjunction with yielding, and tag the helper with _mustcheck to reduce the probabily of improper usage.

Failing to zap a top-level SPTE manifests in one of two ways. If a valid SPTE is skipped by both kvmtdpmmuzapall() and kvmtdpmmuputroot(), the shadow page will be leaked and KVM will WARN accordingly.

WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdpmmu.c:46 [kvm] RIP: 0010:kvmmmuuninittdpmmu+0x3e/0x50 [kvm] Call Trace: <TASK> kvmarchdestroyvm+0x130/0x1b0 [kvm] kvmdestroyvm+0x162/0x2a0 [kvm] kvmvcpurelease+0x34/0x60 [kvm] _fput+0x82/0x240 taskworkrun+0x5c/0x90 doexit+0x364/0xa10 ? futexunqueue+0x38/0x60 dogroupexit+0x33/0xa0 getsignal+0x155/0x850 archdosignalorrestart+0xed/0x750 exittousermodeprepare+0xc5/0x120 syscallexittousermode+0x1d/0x40 dosyscall64+0x48/0xc0 entrySYSCALL64afterhwframe+0x44/0xae

If kvmtdpmmuzapall() skips a gfn/SPTE but that SPTE is then zapped by kvmtdpmmuputroot(), KVM triggers a use-after-free in the form of marking a struct page as dirty/accessed after it has been put back on the free list. This directly triggers a WARN due to encountering a page with page_count() == 0, but it can also lead to data corruption and additional errors in the kernel.

WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvmmain.c:171 RIP: 0010:kvmiszonedevicepfn.part.0+0x9e/0xd0 [kvm] Call Trace: <TASK> kvmsetpfndirty+0x120/0x1d0 [kvm] _handlechangedspte+0x92e/0xca0 [kvm] _handlechangedspte+0x63c/0xca0 [kvm] _handlechangedspte+0x63c/0xca0 [kvm] _handlechangedspte+0x63c/0xca0 [kvm] zapgfnrange+0x549/0x620 [kvm] kvmtdpmmuputroot+0x1b6/0x270 [kvm] mmufreerootpage+0x219/0x2c0 [kvm] kvmmmufreeroots+0x1b4/0x4e0 [kvm] kvmmmuunload+0x1c/0xa0 [kvm] kvmarchdestroyvm+0x1f2/0x5c0 [kvm] kvmputkvm+0x3b1/0x8b0 [kvm] kvmvcpurelease+0x4e/0x70 [kvm] _fput+0x1f7/0x8c0 taskworkrun+0xf8/0x1a0 doexit+0x97b/0x2230 dogroupexit+0xda/0x2a0 getsignal+0x3be/0x1e50 archdosignalorrestart+0x244/0x17f0 exittousermodeprepare+0xcb/0x120 syscallexittousermode+0x1d/0x40 dosyscall64+0x4d/0x90 entrySYSCALL64afterhwframe+0x44/0xae

Note, the underlying bug existed even before commit 1af4a96025b3 ("KVM: x86/mmu: Yield in TDU MMU iter even if no SPTES changed") moved calls to tdpmmuitercondresched() to the beginning of loops, as KVM could still incorrectly advance past a top-level entry when yielding on a lower-level entry. But with respect to leaking shadow pages, the bug was introduced by yielding before processing the current gfn.

Alternatively, tdpmmuitercondresched() could simply fall through, or callers could jump to their "retry" label. The downside of that approach is that tdpmmuitercondresched() must be called before anything else in the loop, and there's no easy way to enfornce that requirement.

Ideally, KVM would handling the cond_resched() fully within the iterator macro (the code is actually quite clean) and avoid this entire class of bugs, but that is extremely difficult do wh ---truncated---(CVE-2021-47094)

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

net: nfc: fix races in nfcllcpsockget() and nfcllcpsockget_sn()

Sili Luo reported a race in nfcllcpsock_get(), leading to UAF.

Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock.

nfcllcpsockgetsn() has a similar problem.

Finally nfcllcprecvsnl() needs to make sure the socket found by nfcllcpsockfrom_sn() does not disappear.(CVE-2023-52502)

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

jfs: fix array-index-out-of-bounds in diNewExt

[Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfsimap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2d0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] _ubsanhandleoutofbounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfsimap.c:2360 diAllocExt fs/jfs/jfsimap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfsimap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfsimap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfsinode.c:56 jfsmkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfsmkdir+0x2f1/0x4b0 fs/namei.c:4106 domkdirat+0x264/0x3a0 fs/namei.c:4129 _dosysmkdir fs/namei.c:4149 [inline] _sesysmkdir fs/namei.c:4147 [inline] _x64sysmkdir+0x6e/0x80 fs/namei.c:4147 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x45/0x110 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

[Analysis] When the agstart is too large, it can cause agno overflow.

[Fix] After obtaining agno, if the value is invalid, exit the subsequent process.

Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter).(CVE-2023-52599)

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

jfs: fix uaf in jfsevictinode

When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcucore() calls jfsfree_node().

Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap.(CVE-2023-52600)

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

jfs: fix array-index-out-of-bounds in dbAdjTree

Currently there is a bound check missing in the dbAdjTree while accessing the dmtstree. To add the required check added the bool isctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)

Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)

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

tomoyo: fix UAF write bug in tomoyowritecontrol()

Since tomoyowritecontrol() updates head->writebuf when write() of long lines is requested, we need to fetch head->writebuf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.(CVE-2024-26622)

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

llc: call sock_orphan() at release time

syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket.

In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling protoops::release()") Eric Biggers hinted that some protocols are missing a sockorphan(), we need to perform a full audit.

In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning.

[1] BUG: KASAN: slab-use-after-free in listempty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueueactive include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sockdefwritespacewfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27

CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 listempty include/linux/list.h:373 [inline] waitqueueactive include/linux/wait.h:127 [inline] sockdefwritespacewfree net/core/sock.c:3384 [inline] sockwfree+0x9a8/0x9d0 net/core/sock.c:2468 skbreleaseheadstate+0xa3/0x2b0 net/core/skbuff.c:1080 skbreleaseall net/core/skbuff.c:1092 [inline] napiconsumeskb+0x119/0x2b0 net/core/skbuff.c:1404 e1000unmapandfreetxresource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000main.c:1970 e1000cleantxirq drivers/net/ethernet/intel/e1000/e1000main.c:3860 [inline] e1000clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000main.c:3801 _napipoll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napipoll net/core/dev.c:6645 [inline] netrxaction+0x956/0xe90 net/core/dev.c:6778 _dosoftirq+0x21a/0x8de kernel/softirq.c:553 runksoftirqd kernel/softirq.c:921 [inline] runksoftirqd+0x31/0x60 kernel/softirq.c:913 smpbootthreadfn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK>

Allocated by task 5167: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:314 [inline] _kasanslaballoc+0x81/0x90 mm/kasan/common.c:340 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3813 [inline] slaballocnode mm/slub.c:3860 [inline] kmemcachealloclru+0x142/0x6f0 mm/slub.c:3879 allocinodesb include/linux/fs.h:3019 [inline] sockallocinode+0x25/0x1c0 net/socket.c:308 allocinode+0x5d/0x220 fs/inode.c:260 newinodepseudo+0x16/0x80 fs/inode.c:1005 sockalloc+0x40/0x270 net/socket.c:634 _sockcreate+0xbc/0x800 net/socket.c:1535 sockcreate net/socket.c:1622 [inline] _syssocketcreate net/socket.c:1659 [inline] _syssocket+0x14c/0x260 net/socket.c:1706 _dosyssocket net/socket.c:1720 [inline] _sesyssocket net/socket.c:1718 [inline] _x64syssocket+0x72/0xb0 net/socket.c:1718 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd3/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Freed by task 0: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] _kasanslabfree+0x121/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inlin ---truncated---(CVE-2024-26625)

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

scsi: core: Move scsihostbusy() out of host lock for waking up EH handler

Inside scsiehwakeup(), scsihostbusy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up.

This can be too heavy in case of recovery, such as:

• N hardware queues

• queue depth is M for each hardware queue

• each scsihostbusy() iterates over (N * M) tag/requests

If recovery is triggered in case that all requests are in-flight, each scsiehwakeup() is strictly serialized, when scsiehwakeup() is called for the last in-flight request, scsihostbusy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times.

If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).

Fix the issue by calling scsihostbusy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that.

mkp: Drop unnecessary 'busy' variables pointed out by Bart