14 lines
14 KiB
JSON
14 lines
14 KiB
JSON
{
|
|
"id": "openEuler-SA-2024-1356",
|
|
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1356",
|
|
"title": "An update for kernel is now available for openEuler-22.03-LTS",
|
|
"severity": "Important",
|
|
"description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86/mmu: Don't advance iterator after restart due to yielding\r\n\r\nAfter dropping mmu_lock in the TDP MMU, restart the iterator during\ntdp_iter_next() and do not advance the iterator. Advancing the iterator\nresults in skipping the top-level SPTE and all its children, which is\nfatal if any of the skipped SPTEs were not visited before yielding.\r\n\r\nWhen zapping all SPTEs, i.e. when min_level == root_level, restarting the\niter and then invoking tdp_iter_next() is always fatal if the current gfn\nhas as a valid SPTE, as advancing the iterator results in try_step_side()\nskipping the current gfn, which wasn't visited before yielding.\r\n\r\nSprinkle WARNs on iter->yielded being true in various helpers that are\noften used in conjunction with yielding, and tag the helper with\n__must_check to reduce the probabily of improper usage.\r\n\r\nFailing to zap a top-level SPTE manifests in one of two ways. If a valid\nSPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),\nthe shadow page will be leaked and KVM will WARN accordingly.\r\n\r\n WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]\n RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]\n Call Trace:\n <TASK>\n kvm_arch_destroy_vm+0x130/0x1b0 [kvm]\n kvm_destroy_vm+0x162/0x2a0 [kvm]\n kvm_vcpu_release+0x34/0x60 [kvm]\n __fput+0x82/0x240\n task_work_run+0x5c/0x90\n do_exit+0x364/0xa10\n ? futex_unqueue+0x38/0x60\n do_group_exit+0x33/0xa0\n get_signal+0x155/0x850\n arch_do_signal_or_restart+0xed/0x750\n exit_to_user_mode_prepare+0xc5/0x120\n syscall_exit_to_user_mode+0x1d/0x40\n do_syscall_64+0x48/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nIf kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by\nkvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of\nmarking a struct page as dirty/accessed after it has been put back on the\nfree list. This directly triggers a WARN due to encountering a page with\npage_count() == 0, but it can also lead to data corruption and additional\nerrors in the kernel.\r\n\r\n WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171\n RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]\n Call Trace:\n <TASK>\n kvm_set_pfn_dirty+0x120/0x1d0 [kvm]\n __handle_changed_spte+0x92e/0xca0 [kvm]\n __handle_changed_spte+0x63c/0xca0 [kvm]\n __handle_changed_spte+0x63c/0xca0 [kvm]\n __handle_changed_spte+0x63c/0xca0 [kvm]\n zap_gfn_range+0x549/0x620 [kvm]\n kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]\n mmu_free_root_page+0x219/0x2c0 [kvm]\n kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]\n kvm_mmu_unload+0x1c/0xa0 [kvm]\n kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]\n kvm_put_kvm+0x3b1/0x8b0 [kvm]\n kvm_vcpu_release+0x4e/0x70 [kvm]\n __fput+0x1f7/0x8c0\n task_work_run+0xf8/0x1a0\n do_exit+0x97b/0x2230\n do_group_exit+0xda/0x2a0\n get_signal+0x3be/0x1e50\n arch_do_signal_or_restart+0x244/0x17f0\n exit_to_user_mode_prepare+0xcb/0x120\n syscall_exit_to_user_mode+0x1d/0x40\n do_syscall_64+0x4d/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nNote, the underlying bug existed even before commit 1af4a96025b3 (\"KVM:\nx86/mmu: Yield in TDU MMU iter even if no SPTES changed\") moved calls to\ntdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still\nincorrectly advance past a top-level entry when yielding on a lower-level\nentry. But with respect to leaking shadow pages, the bug was introduced\nby yielding before processing the current gfn.\r\n\r\nAlternatively, tdp_mmu_iter_cond_resched() could simply fall through, or\ncallers could jump to their \"retry\" label. The downside of that approach\nis that tdp_mmu_iter_cond_resched() _must_ be called before anything else\nin the loop, and there's no easy way to enfornce that requirement.\r\n\r\nIdeally, KVM would handling the cond_resched() fully within the iterator\nmacro (the code is actually quite clean) and avoid this entire class of\nbugs, but that is extremely difficult do wh\n---truncated---(CVE-2021-47094)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()\r\n\r\nSili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.\r\n\r\nGetting a reference on the socket found in a lookup while\nholding a lock should happen before releasing the lock.\r\n\r\nnfc_llcp_sock_get_sn() has a similar problem.\r\n\r\nFinally nfc_llcp_recv_snl() needs to make sure the socket\nfound by nfc_llcp_sock_from_sn() does not disappear.(CVE-2023-52502)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diNewExt\r\n\r\n[Syz report]\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2\nindex -878706688 is out of range for type 'struct iagctl[128]'\nCPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:217 [inline]\n __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348\n diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360\n diAllocExt fs/jfs/jfs_imap.c:1949 [inline]\n diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666\n diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225\n vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106\n do_mkdirat+0x264/0x3a0 fs/namei.c:4129\n __do_sys_mkdir fs/namei.c:4149 [inline]\n __se_sys_mkdir fs/namei.c:4147 [inline]\n __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\nRIP: 0033:0x7fcb7e6a0b57\nCode: 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\nRSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053\nRAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57\nRDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140\nRBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\r\n\r\n[Analysis]\nWhen the agstart is too large, it can cause agno overflow.\r\n\r\n[Fix]\nAfter obtaining agno, if the value is invalid, exit the subsequent process.\r\n\r\n\nModified the test from agno > MAXAG to agno >= MAXAG based on linux-next\nreport by kernel test robot (Dan Carpenter).(CVE-2023-52599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix uaf in jfs_evict_inode\r\n\r\nWhen the execution of diMount(ipimap) fails, the object ipimap that has been\nreleased may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs\nwhen rcu_core() calls jfs_free_node().\r\n\r\nTherefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as\nipimap.(CVE-2023-52600)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbAdjTree\r\n\r\nCurrently there is a bound check missing in the dbAdjTree while\naccessing the dmt_stree. To add the required check added the bool is_ctl\nwhich is required to determine the size as suggest in the following\ncommit.\nhttps://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)\r\n\r\nInteger Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntomoyo: fix UAF write bug in tomoyo_write_control()\r\n\r\nSince tomoyo_write_control() updates head->write_buf when write()\nof long lines is requested, we need to fetch head->write_buf after\nhead->io_sem is held. Otherwise, concurrent write() requests can\ncause use-after-free-write and double-free problems.(CVE-2024-26622)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: call sock_orphan() at release time\r\n\r\nsyzbot reported an interesting trace [1] caused by a stale sk->sk_wq\npointer in a closed llc socket.\r\n\r\nIn commit ff7b11aa481f (\"net: socket: set sock->sk to NULL after\ncalling proto_ops::release()\") Eric Biggers hinted that some protocols\nare missing a sock_orphan(), we need to perform a full audit.\r\n\r\nIn net-next, I plan to clear sock->sk from sock_orphan() and\namend Eric patch to add a warning.\r\n\r\n[1]\n BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]\n BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]\n BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\nRead of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27\r\n\r\nCPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc4/0x620 mm/kasan/report.c:488\n kasan_report+0xda/0x110 mm/kasan/report.c:601\n list_empty include/linux/list.h:373 [inline]\n waitqueue_active include/linux/wait.h:127 [inline]\n sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\n skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080\n skb_release_all net/core/skbuff.c:1092 [inline]\n napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404\n e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970\n e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]\n e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801\n __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576\n napi_poll net/core/dev.c:6645 [inline]\n net_rx_action+0x956/0xe90 net/core/dev.c:6778\n __do_softirq+0x21a/0x8de kernel/softirq.c:553\n run_ksoftirqd kernel/softirq.c:921 [inline]\n run_ksoftirqd+0x31/0x60 kernel/softirq.c:913\n smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164\n kthread+0x2c6/0x3a0 kernel/kthread.c:388\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242\n </TASK>\r\n\r\nAllocated by task 5167:\n kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3019 [inline]\n sock_alloc_inode+0x25/0x1c0 net/socket.c:308\n alloc_inode+0x5d/0x220 fs/inode.c:260\n new_inode_pseudo+0x16/0x80 fs/inode.c:1005\n sock_alloc+0x40/0x270 net/socket.c:634\n __sock_create+0xbc/0x800 net/socket.c:1535\n sock_create net/socket.c:1622 [inline]\n __sys_socket_create net/socket.c:1659 [inline]\n __sys_socket+0x14c/0x260 net/socket.c:1706\n __do_sys_socket net/socket.c:1720 [inline]\n __se_sys_socket net/socket.c:1718 [inline]\n __x64_sys_socket+0x72/0xb0 net/socket.c:1718\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFreed by task 0:\n kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\n poison_slab_object mm/kasan/common.c:241 [inline]\n __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257\n kasan_slab_free include/linux/kasan.h:184 [inline]\n slab_free_hook mm/slub.c:2121 [inlin\n---truncated---(CVE-2024-26625)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Move scsi_host_busy() out of host lock for waking up EH handler\r\n\r\nInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host\nlock every time for deciding if error handler kthread needs to be waken up.\r\n\r\nThis can be too heavy in case of recovery, such as:\r\n\r\n - N hardware queues\r\n\r\n - queue depth is M for each hardware queue\r\n\r\n - each scsi_host_busy() iterates over (N * M) tag/requests\r\n\r\nIf recovery is triggered in case that all requests are in-flight, each\nscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called\nfor the last in-flight request, scsi_host_busy() has been run for (N * M -\n1) times, and request has been iterated for (N*M - 1) * (N * M) times.\r\n\r\nIf both N and M are big enough, hard lockup can be triggered on acquiring\nhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).\r\n\r\nFix the issue by calling scsi_host_busy() outside the host lock. We don't\nneed the host lock for getting busy count because host the lock never\ncovers that.\r\n\r\n[mkp: Drop unnecessary 'busy' variables pointed out by Bart](CVE-2024-26627)",
|
|
"cves": [
|
|
{
|
|
"id": "CVE-2024-26627",
|
|
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26627",
|
|
"severity": "Important"
|
|
}
|
|
]
|
|
} |