CentOS Linux 8.5 主機安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1771077729 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

  - 已解決 Linux 核心中的下列弱點：dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

  - 已解決 Linux 核心中的下列弱點：tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event
    __unregister_trace_event (second call) Fix the bug by avoiding to call the second
    __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code:
    00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP:
    0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08:
    0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49799)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1771078945 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已解決 Linux 核心中的下列弱點：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

CentOS Linux 7 主機安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1778756832 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：scsi: scsi_debug: Fix out-of-bound read in resp_readcap16() The following warning was observed running syzkaller: [ 3813.830724] sg_write:
    data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor not setting count and/or reply_len properly [ 3813.836956] ================================================================== [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329] scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB=00 000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff61 96a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d], 0x126) In resp_readcap16() we get int alloc_len value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32.
    (CVE-2021-47191)

  - 已解決 Linux 核心中的下列弱點：scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs() The following issue was observed running syzkaller: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815 CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
    __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe We get 'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'.
    Switch n, alen, and rlen to u32. (CVE-2021-47219)

  - 已解決 Linux 核心中的下列弱點：kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.
    (CVE-2021-47277)

  - 已解決 Linux 核心中的下列弱點：KVM: x86/mmu: make apf token non-zero to fix bug In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event. This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70
    __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09:
    0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000 (CVE-2022-48943)

  - 已解決 Linux 核心中的下列弱點：ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network,
    __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at:
    slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398
    __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954
    __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437
    __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized. (CVE-2022-49865)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 5.15.79-51.138。因此，會受到 ALAS2KERNEL-515-2022-011 公告中所提及的多個弱點影響。

    在 Linux 核心中發現一個歸類為「有問題」的弱點。這會影響 IPv4 處置程式元件中 net/ipv4/fib_semantics.c 檔案的 fib_nh_match 函式。操控此弱點可導致超出邊界讀取。攻擊者可從遠端發動攻擊。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-210357。(CVE-2022-3435)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。受到此弱點影響的是 IPv6 Handler 元件的 ipv6_renew_options 函式。攻擊者可利用此弱點造成記憶體洩漏。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。
    已爲此弱點指派識別碼 VDB-211021。(CVE-2022-3524)

    在 Linux 核心中發現一個歸類爲「有問題」的弱點。此問題會影響 BPF 元件中 net/unix/af_unix.c 檔案的 unix_sock_destructor/unix_release_sock 函式。
    攻擊者可利用此弱點造成記憶體洩漏。建議套用修補程式以修正此問題。此弱點的相關識別碼是 VDB-211043。(CVE-2022-3543)

    在 Linux 核心中發現一個歸類為「嚴重」的弱點。此弱點會影響 Bluetooth 元件中 net/bluetooth/l2cap_core.c 檔案的 l2cap_reassemble_sdu 函式。操控此弱點可導致釋放後使用。建議套用修補程式以修正此問題。此弱點的相關識別碼是 VDB-211087。(CVE-2022-3564)

    在 Linux 核心中發現一個歸類爲「有問題」的弱點。此弱點會影響 Bluetooth 元件中 net/bluetooth/l2cap_core.c 檔案的 l2cap_recv_acldata 函式。攻擊者可利用此弱點造成記憶體洩漏。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211918。(CVE-2022-3619)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。此弱點會影響 BPF 元件中 mm/gup.c 檔案的 follow_page_pte 函式。利用此弱點可導致爭用情形。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211921。(CVE-2022-3623)

    在 Linux 核心中，下列弱點已解決：

    btrfszoned初始化裝置的區域資訊以進行植入 (CVE-2022-49831)

    在 Linux 核心中，下列弱點已解決：

    udf：修正 udf_find_entry() 中的 slab-out-of-bounds 寫入錯誤 (CVE-2022-49846)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正 dev_args_match_device 中不正確的比對 (CVE-2022-49849)

    在 Linux 核心中，下列弱點已解決：

    net：macvlan：修正 macvlan_common_newlink 的記憶體洩漏 (CVE-2022-49853)

    在 Linux 核心中，下列弱點已解決：

    canaf_can修正 can_rx_register() 中的 NULL 指標解除參照 (CVE-2022-49863)

    在 Linux 核心中，下列弱點已解決：

    ipv6：addrlabel：修正將結構 ifaddrlblmsg 傳送至網路時的資訊洩漏 (CVE-2022-49865)

    在 Linux 核心中，下列弱點已解決：

    capabilities：修正對 CAP_TO_MASK 進行位移運算時的未定義行為 (CVE-2022-49870)

    在 Linux 核心中，下列弱點已解決：

    nettun修正 napi_get_frags 的記憶體洩漏 (CVE-2022-49871)

    在 Linux 核心中，下列弱點已解決：

    net：gso：修正具有混合 head alloc 類型的 frag_list 上的錯誤 (CVE-2022-49872)

    在 Linux 核心中，下列弱點已解決：

    bpf修正 release_reference() 中錯誤的 reg 類型轉換 (CVE-2022-49873)

    在 Linux 核心中，下列弱點已解決：

    HID：hyperv：修正 mousevsc_probe() 中的潛在記憶體洩漏 (CVE-2022-49874)

    在 Linux 核心中，下列弱點已解決：

    bpftool修正當釘選 {PROG, MAP, LINK} without FILE 時的 NULL 指標解除參照 (CVE-2022-49875)

    在 Linux 核心中，下列弱點已解決：

    bpf、sockmap修正 sk_stream_kill_queues 的 sk->sk_forward_alloc 警告 (CVE-2022-49877)

    在 Linux 核心中，下列弱點已解決：

    bpf、verifier修正堆疊狀態的陣列重新配置中的記憶體洩漏 (CVE-2022-49878)

    在 Linux 核心中，下列弱點已解決：

    ext4修正目錄項目具有無效 rec_len 時的 BUG_ON() (CVE-2022-49879)

    在 Linux 核心中，下列弱點已解決：

    ext4：修正「ext4_da_release_space」中的警告 (CVE-2022-49880)

    在 Linux 核心中，下列弱點已解決：

    ACPIAPEI修正 ghes_estatus_pool_init() 中的整數溢位 (CVE-2022-49885)

    在 Linux 核心中，下列弱點已解決：

    arm64項目避免 kprobe 遞回 (CVE-2022-49888)

    在 Linux 核心中，下列弱點已解決：

    ring-buffer在 ring_buffer_wake_waiters() 中檢查 NULL cpu_buffer (CVE-2022-49889)

    在 Linux 核心中，下列弱點已解決：

    capabilities：從 vfs_getxattr_alloc() 修正錯誤路徑上的潛在記憶體洩漏 (CVE-2022-49890)

    在 Linux 核心中，下列弱點已解決：

    ftrace修正動態 ftrace_ops 的釋放後使用 (CVE-2022-49892)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正樹狀結構 mod 記錄不當處理重新配置的節點 (CVE-2022-49898)

    在 Linux 核心中，下列弱點已解決：

    fscrypt停止使用 fscrypt_master_key 的 keyring 子系統 (CVE-2022-49899)

    在 Linux 核心中，下列弱點已解決：

    block修正 add_disk 失敗時 rq_wb 可能發生的記憶體洩漏 (CVE-2022-49902)

    在 Linux 核心中，下列弱點已解決：

    ipv6修正 ip6_route_net_exit_late() 中的警告 (CVE-2022-49903)

    在 Linux 核心中，下列弱點已解決：

    net、neigh：修正 neigh_table_clear() 中的 null-ptr-deref (CVE-2022-49904)

    在 Linux 核心中，下列弱點已解決：

    net/smc修正 smc_init() 中可能洩漏的 pernet 命名空間 (CVE-2022-49905)

    在 Linux 核心中，下列弱點已解決：

    net：mdio：為 __mdiobus_register 修正位元移位中的未定義行為 (CVE-2022-49907)

    在 Linux 核心中，下列弱點已解決：

    netfilteripset強制執行記錄的限制以防止配置大量記憶體 (CVE-2022-49911)

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正 qgroup 自我測試之錯誤路徑中的 ulist 洩漏 (CVE-2022-49912)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正反向參照搜尋期間於 find_parent_nodes() 發生的 inode 清單洩漏 (CVE-2022-49913)

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正反向參照搜尋期間於 resolve_indirect_refs() 發生的 inode 清單洩漏 (CVE-2022-49914)

    在 Linux 核心中，下列弱點已解決：

    mISDN：修正 mISDN_register_device() 中可能發生的記憶體洩漏 (CVE-2022-49915)

    在 Linux 核心中，下列弱點已解決：

    ipvs修正 ip_vs_app_net_cleanup() 中的警告 (CVE-2022-49917)

    在 Linux 核心中，下列弱點已解決：

    ipvs修正 __ip_vs_cleanup_batch() 中的警告 (CVE-2022-49918)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_tables從認可路徑釋放流程規則物件 (CVE-2022-49919)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_tablesnetlink 通知程式可能會爭用釋放物件 (CVE-2022-49920)

    在 Linux 核心中，下列弱點已解決：

    net：sched：修正 red_enqueue() 中的釋放後使用 (CVE-2022-49921)

    在 Linux 核心中，下列弱點已解決：

    RDMA/核心修正 ib_core_cleanup() 中的 null-ptr-deref (CVE-2022-49925)

    在 Linux 核心中，下列弱點已解決：

    nfs4：修正配置插槽失敗時的 kmemleak (CVE-2022-49927)

    在 Linux 核心中，下列弱點已解決：

    SUNRPC當 xps sysfs 配置失敗時修正 null-ptr-deref (CVE-2022-49928)

    在 Linux 核心中，下列弱點已解決：

    kcm註解 kcm->rx_wait 的資料爭用 (CVE-2022-50265)

    在 Linux 核心中，下列弱點已解決：

    mm、hugetlb在遞減 h->resv_huge_pages 前取得 hugetlb_lock (CVE-2022-50285)

    在 Linux 核心中，下列弱點已解決：

    kcm註釋 kcm->rx_psock 的資料爭用 (CVE-2022-50291)

    在 Linux 核心中，下列弱點已解決：

    ataahci比對 EM_MAX_SLOTS 和 SATA_PMP_MAX_PORTS (CVE-2022-50315)

    在 Linux 核心中，下列弱點已解決：

    net未感應 skb_append_pagefrags() 中的 pfmemalloc 狀態 (CVE-2022-50323)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_create() 中的 xid 洩漏 (CVE-2022-50351)

    在 Linux 核心中，下列弱點已解決：

    netschedsfb修正 sfb_init() 失敗時的 NULL 指標存取問題 (CVE-2022-50356)

    在 Linux 核心中，下列弱點已解決：

    mm/proc/pid/smaps_rollup修正任何 vma 的 null-deref (CVE-2022-50380)

    在 Linux 核心中，下列弱點已解決：

    kernfs修正 __kernfs_remove 中的釋放後使用 (CVE-2022-50432)

    在 Linux 核心中，下列弱點已解決：

    netschedcake修正 cake_init() 失敗時的 NULL 指標存取問題 (CVE-2022-50452)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_flock() 中的 xid 洩漏 (CVE-2022-50460)

    在 Linux 核心中，下列弱點已解決：

    fs/binfmt_elf修正 load_elf_binary() 中的記憶體洩漏 (CVE-2022-50466)

    在 Linux 核心中，下列弱點已解決：

    xhci釋放裝置時從頻寬清單中移除裝置端點 (CVE-2022-50470)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d清理 init_dmars() 錯誤路徑中的 si_domain (CVE-2022-50482)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_copy_file_range() 中的 xid 洩漏 (CVE-2022-50643)

    在 Linux 核心中，下列弱點已解決：

    ethtooleeprom修正轉儲存中 genl_info 的 null-deref (CVE-2022-50651)

    在 Linux 核心中，下列弱點已解決：

    selinux在 convert_context() 中啟用 GFP_KERNEL 和 GFP_ATOMIC 的使用 (CVE-2022-50699)

    在 Linux 核心中，下列弱點已解決：

    net修正 ops_init() 失敗時nfqnl_nf_hook_drop() 中的 UAF 問題 (CVE-2022-50780)

    在 Linux 核心中，下列弱點已解決：

    ipv6確保通道中的裝置 mtu 正常 (CVE-2022-50816)

    在 Linux 核心中，下列弱點已解決：

    nethsr避免 skb_clone() 中可能的 NULL 解除參照 (CVE-2022-50817)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_ses_add_channel() 中的 xid 洩漏 (CVE-2022-50856)

    在 Linux 核心中，下列弱點已解決：

    tcp修正 tcp_add_backlog() 中的帶正負號整數溢位錯誤 (CVE-2022-50865)

    據發現，在 Linux 核心中，由於爭用問題，net/sched/sch_api.c 的 qdisc_graft 中存在釋放後使用缺陷。此缺陷可導致拒絕服務問題。(CVE-2023-0590)

    在 Linux 核心的 TUN/TAP 裝置驅動程式功能中發現超出邊界記憶體存取缺陷，該缺陷涉及使用者在啟用 napi frags 時產生惡意網路封包 (過大) 的方式。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2023-3812)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 5.4.226-129.415。因此，會受到 ALAS2KERNEL-5.4-2024-071 公告中所提及的多個弱點影響。

    在 Linux 核心中發現一個缺陷。如果透過驅動程式的裝置檔案連續要求 NVME_IOCTL_RESET 和 NVME_IOCTL_SUBSYS_RESET，可能會發生拒絕服務，進而導致 PCIe 連結中斷。(CVE-2022-3169)

    在 Linux 核心中發現一個歸類為「有問題」的弱點。這會影響 IPv4 處置程式元件中 net/ipv4/fib_semantics.c 檔案的 fib_nh_match 函式。操控此弱點可導致超出邊界讀取。攻擊者可從遠端發動攻擊。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-210357。(CVE-2022-3435)

    在 Linux 核心中，下列弱點已解決：

    char：tpm：使用鎖定保護 tpm_pm_suspend (CVE-2022-48997)

    在 Linux 核心中，下列弱點已解決：

    ipv4：當 fib_info 包含 nh 參照時，處理刪除多重路徑路由的嘗試 (CVE-2022-48999)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d：修正 dmar_dev_scope_init() 中的 PCI 裝置 refcount 洩漏 (CVE-2022-49002)

    在 Linux 核心中，下列弱點已解決：

    追踪：移除使用的動態事件時釋放緩衝區 (CVE-2022-49006)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正 nilfs_palloc_commit_free_entry() 中的 NULL 指標解除參照 (CVE-2022-49007)

    在 Linux 核心中，下列弱點已解決：

    sctp：修正 sctp_stream_outq_migrate() 中的記憶體洩漏 (CVE-2022-49013)

    在 Linux 核心中，下列弱點已解決：

    net：tun：修正 tun_detach() 中的釋放後使用 (CVE-2022-49014)

    在 Linux 核心中，下列弱點已解決 :

    net：hsr：修復潛在的釋放後使用問題 (CVE-2022-49015)

    在 Linux 核心中，下列弱點已解決：

    net：phy：在 probe() 失敗時修正 null-ptr-deref (CVE-2022-49021)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e：修正還原終止表格時的釋放後使用 (CVE-2022-49025)

    在 Linux 核心中，下列弱點已解決：

    btrfs：qgroup：修復 btrfs_qgroup_inherit() 中無效內容錯誤的 Sleep (CVE-2022-49033)

    在 Linux 核心中，下列弱點已解決：

    ntfs：迭代 ATTR_RECORD 時檢查溢位情況 (CVE-2022-49762)

    在 Linux 核心中，下列弱點已解決：

    ntfs：修正 ntfs_attr_find() 中的釋放後使用 (CVE-2022-49763)

    在 Linux 核心中，下列弱點已解決：

    gfs2：讀取超級區塊後檢查 sb_bsize_shift (CVE-2022-49769)

    在 Linux 核心中，下列弱點已解決：

    Ceph：當解碼快照失敗時，避免將領域放置兩次 （CVE-2022-49770）

    在 Linux 核心中，下列弱點已解決：

    dm ioctl：修正 list_versions 與模組載入爭用時的錯誤行為 (CVE-2022-49771)

    在 Linux 核心中，下列弱點已解決：

    macvlan：強制執行一致的最小 mtu (CVE-2022-49776)

    在 Linux 核心中，下列弱點已解決：

    輸入：i8042 - 修正模組移除時平台裝置洩漏 （CVE-2022-49777）

    在 Linux 核心中，下列弱點已解決：

    kprobes：跳過 kprobe-on-ftrace 案例中清除 aggrprobe 的post_handler （CVE-2022-49779）

    在 Linux 核心中，下列弱點已解決：

    scsi： target： tcm_loop：修正 tcm_loop_setup_hba_bus（） 中可能的名稱洩漏 （CVE-2022-49780）

    在 Linux 核心中，下列弱點已解決：

    mmc：sdhci-pci：修正因缺少 pci_dev_put() 而可能造成的記憶體洩漏 (CVE-2022-49787)

    在 Linux 核心中，下列弱點已解決：

    misc/vmw_vmci：修正 vmci_host_do_receive_datagram() 中的資訊洩漏 (CVE-2022-49788)

    在 Linux 核心中，下列弱點已解決：

    ftrace：修正 ftrace_add_mod() 中的 null 指標解除參照 (CVE-2022-49802)

    在 Linux 核心中，下列弱點已解決：

    drbd：drbd_create_device() 中有釋放後使用錯誤 (CVE-2022-49811)

    在 Linux 核心中，下列弱點已解決：

    kcm：關閉 sk_receive_queue 上的爭用情形 (CVE-2022-49814)

    在 Linux 核心中，下列弱點已解決：

    ata： libata-transport：修正 ata_tport_add（）CVE-2022-49826 中的雙 ata_host_put（） （）

    在 Linux 核心中，下列弱點已解決：

    pinctrl：devicetree：修正 pinctrl_dt_to_map 中的 null 指標解除參照 (CVE-2022-49832)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正重新掛載時 ns_writer 的釋放後使用錯誤 (CVE-2022-49834)

    在 Linux 核心中，下列弱點已解決：

    bpf、test_run：修正 bpf_prog_test_run_skb() 中的對齊問題 (CVE-2022-49840)

    在 Linux 核心中，下列弱點已解決：

    ASoC: core: 修復 snd_soc_exit() 中的釋放後使用問題 (CVE-2022-49842)

    在 Linux 核心中，下列弱點已解決：

    can： j1939： j1939_send_one（）：修正缺少的 CAN 標頭初始化 （CVE-2022-49845）

    在 Linux 核心中，下列弱點已解決：

    udf：修正 udf_find_entry() 中的 slab-out-of-bounds 寫入錯誤 (CVE-2022-49846)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正 nilfs_count_free_blocks() 中的鎖死 (CVE-2022-49850)

    在 Linux 核心中，下列弱點已解決：

    net：macvlan：修正 macvlan_common_newlink 的記憶體洩漏 (CVE-2022-49853)

    在 Linux 核心中，下列弱點已解決：

    tipc：修正 tipc_nl_compat_name_table_dump_header 中的 msg->req tlv len 檢查 (CVE-2022-49862)

    在 Linux 核心中，下列弱點已解決：

    can： af_can：修正 can_rx_register（） 中的 NULL 指標解除參照 （CVE-2022-49863）

    在 Linux 核心中，下列弱點已解決：

    ipv6：addrlabel：修正將結構 ifaddrlblmsg 傳送至網路時的資訊洩漏 (CVE-2022-49865)

    在 Linux 核心中，下列弱點已解決：

    bnxt_en：修正 bnxt_hwrm_set_coal（） 中可能的損毀 （CVE-2022-49869）

    在 Linux 核心中，下列弱點已解決：

    capabilities：修正對 CAP_TO_MASK 進行位移運算時的未定義行為 (CVE-2022-49870)

    在 Linux 核心中，下列弱點已解決：

    net： tun：修正 napi_get_frags （CVE-2022-49871） 的記憶體洩漏

    在 Linux 核心中，下列弱點已解決：

    net：gso：修正具有混合 head alloc 類型的 frag_list 上的錯誤 (CVE-2022-49872)

    在 Linux 核心中，下列弱點已解決：

    HID：hyperv：修正 mousevsc_probe() 中的潛在記憶體洩漏 (CVE-2022-49874)

    在 Linux 核心中，下列弱點已解決：

    bpf， sockmap：修正 sk_stream_kill_queues （CVE-2022-49877） 的 sk->sk_forward_alloc 警告

    在 Linux 核心中發現一個資料爭用缺陷，介於配置 con 的位置和設定 con->sock 的位置之間。在 Linux 核心的 tipc 通訊協定中，存取 net/tipc/topsrv.c 中的 con->sock->sk 時，此問題會導致 NULL 指標解除參照。(CVE-2023-1382)

    在 Linux 核心 6.0.8 版本中，fs/ntfs/attrib.c 的 ntfs_attr_find 中有超出邊界讀取情形。
    (CVE-2023-26607)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 5.10.155-138.670。因此，會受到 ALAS2KERNEL-5.10-2022-023 公告中所提及的多個弱點影響。

    在 Linux 核心中 memcg 子系統的 ipc 功能中發現記憶體溢位弱點，使用者會多次呼叫 semget 函式，從而建立旗號。本機使用者可利用此缺陷耗盡資源，進而引發拒絕服務。此弱點對系統可用性威脅最大。(CVE-2021-3759)

    在 Linux 核心中，下列弱點已解決：

    inet：將 sk->sk_rx_dst 完全轉換為 RCU 規則 (CVE-2021-47103)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。受到此弱點影響的是 IPv6 Handler 元件的 ipv6_renew_options 函式。攻擊者可利用此弱點造成記憶體洩漏。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。
    已爲此弱點指派識別碼 VDB-211021。(CVE-2022-3524)

    在 Linux 核心中發現一個歸類為「有問題」的弱點。此弱點會影響 BPF 元件中 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c 檔案的 bnx2x_tpa_stop 函式。
    攻擊者可利用此弱點造成記憶體洩漏。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211042。(CVE-2022-3542)

    在 Linux 核心中發現一個歸類為「嚴重」的弱點。此弱點會影響 Bluetooth 元件中 net/bluetooth/l2cap_core.c 檔案的 l2cap_reassemble_sdu 函式。操控此弱點可導致釋放後使用。建議套用修補程式以修正此問題。此弱點的相關識別碼是 VDB-211087。(CVE-2022-3564)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。此弱點會影響 BPF 元件中 drivers/net/usb/r8152.c 檔案的 intr_callback 函式。利用此弱點可造成程式記錄過量資料。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。此弱點的相關識別碼是 VDB-211363。
    (CVE-2022-3594)

    在 Linux 核心中，下列弱點已解決：

    arm64：拓撲：修正 amu_fie_setup() 中可能發生的溢位問題 (CVE-2022-48657)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正重新掛載時 ns_writer 的釋放後使用錯誤 (CVE-2022-49834)

    在 Linux 核心中，下列弱點已解決：

    canj1939j1939_send_one()修正遺漏的 CAN 標頭初始化 (CVE-2022-49845)

    在 Linux 核心中，下列弱點已解決：

    udf：修正 udf_find_entry() 中的 slab-out-of-bounds 寫入錯誤 (CVE-2022-49846)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正 nilfs_count_free_blocks() 中的鎖死 (CVE-2022-49850)

    在 Linux 核心中，下列弱點已解決：

    net：macvlan：修正 macvlan_common_newlink 的記憶體洩漏 (CVE-2022-49853)

    在 Linux 核心中，下列弱點已解決：

    tipc：修正 tipc_nl_compat_name_table_dump_header 中的 msg->req tlv len 檢查 (CVE-2022-49862)

    在 Linux 核心中，下列弱點已解決：

    canaf_can修正 can_rx_register() 中的 NULL 指標解除參照 (CVE-2022-49863)

    在 Linux 核心中，下列弱點已解決：

    ipv6：addrlabel：修正將結構 ifaddrlblmsg 傳送至網路時的資訊洩漏 (CVE-2022-49865)

    在 Linux 核心中，下列弱點已解決：

    bnxt_en修正 bnxt_hwrm_set_coal() 中可能發生的當機 (CVE-2022-49869)

    在 Linux 核心中，下列弱點已解決：

    capabilities：修正對 CAP_TO_MASK 進行位移運算時的未定義行為 (CVE-2022-49870)

    在 Linux 核心中，下列弱點已解決：

    nettun修正 napi_get_frags 的記憶體洩漏 (CVE-2022-49871)

    在 Linux 核心中，下列弱點已解決：

    net：gso：修正具有混合 head alloc 類型的 frag_list 上的錯誤 (CVE-2022-49872)

    在 Linux 核心中，下列弱點已解決：

    bpf修正 release_reference() 中錯誤的 reg 類型轉換 (CVE-2022-49873)

    在 Linux 核心中，下列弱點已解決：

    HID：hyperv：修正 mousevsc_probe() 中的潛在記憶體洩漏 (CVE-2022-49874)

    在 Linux 核心中，下列弱點已解決：

    bpftool修正當釘選 {PROG, MAP, LINK} without FILE 時的 NULL 指標解除參照 (CVE-2022-49875)

    在 Linux 核心中，下列弱點已解決：

    bpf、sockmap修正 sk_stream_kill_queues 的 sk->sk_forward_alloc 警告 (CVE-2022-49877)

    在 Linux 核心中，下列弱點已解決：

    ext4修正目錄項目具有無效 rec_len 時的 BUG_ON() (CVE-2022-49879)

    在 Linux 核心中，下列弱點已解決：

    ext4：修正「ext4_da_release_space」中的警告 (CVE-2022-49880)

    在 Linux 核心中，下列弱點已解決：

    ACPIAPEI修正 ghes_estatus_pool_init() 中的整數溢位 (CVE-2022-49885)

    在 Linux 核心中，下列弱點已解決：

    capabilities：從 vfs_getxattr_alloc() 修正錯誤路徑上的潛在記憶體洩漏 (CVE-2022-49890)

    在 Linux 核心中，下列弱點已解決：

    ftrace修正動態 ftrace_ops 的釋放後使用 (CVE-2022-49892)

    在 Linux 核心中，下列弱點已解決：

    fscrypt停止使用 fscrypt_master_key 的 keyring 子系統 (CVE-2022-49899)

    在 Linux 核心中，下列弱點已解決：

    ipv6修正 ip6_route_net_exit_late() 中的警告 (CVE-2022-49903)

    在 Linux 核心中，下列弱點已解決：

    net、neigh：修正 neigh_table_clear() 中的 null-ptr-deref (CVE-2022-49904)

    在 Linux 核心中，下列弱點已解決：

    net：mdio：為 __mdiobus_register 修正位元移位中的未定義行為 (CVE-2022-49907)

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正 qgroup 自我測試之錯誤路徑中的 ulist 洩漏 (CVE-2022-49912)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正反向參照搜尋期間於 find_parent_nodes() 發生的 inode 清單洩漏 (CVE-2022-49913)

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正反向參照搜尋期間於 resolve_indirect_refs() 發生的 inode 清單洩漏 (CVE-2022-49914)

    在 Linux 核心中，下列弱點已解決：

    mISDN：修正 mISDN_register_device() 中可能發生的記憶體洩漏 (CVE-2022-49915)

    在 Linux 核心中，下列弱點已解決：

    ipvs修正 ip_vs_app_net_cleanup() 中的警告 (CVE-2022-49917)

    在 Linux 核心中，下列弱點已解決：

    ipvs修正 __ip_vs_cleanup_batch() 中的警告 (CVE-2022-49918)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_tables從認可路徑釋放流程規則物件 (CVE-2022-49919)

    在 Linux 核心中，下列弱點已解決：

    net：sched：修正 red_enqueue() 中的釋放後使用 (CVE-2022-49921)

    在 Linux 核心中，下列弱點已解決：

    RDMA/核心修正 ib_core_cleanup() 中的 null-ptr-deref (CVE-2022-49925)

    在 Linux 核心中，下列弱點已解決：

    nfs4：修正配置插槽失敗時的 kmemleak (CVE-2022-49927)

    在 Linux 核心中，下列弱點已解決：

    binder修正 alloc->vma 在與 munmap() 爭用中的 UAF (CVE-2022-50240)

    在 Linux 核心中，下列弱點已解決：

    NFSD修正執行伺服器間複製時來源伺服器上的釋放後使用 (CVE-2022-50241)

    在 Linux 核心中，下列弱點已解決：

    sctp處理從 sctp_auth_asoc_init_active_key 傳回的錯誤 (CVE-2022-50243)

    在 Linux 核心中，下列弱點已解決：

    xen/gntdev防止洩漏授權 (CVE-2022-50257)

    在 Linux 核心中，下列弱點已解決：

    kcm註解 kcm->rx_wait 的資料爭用 (CVE-2022-50265)

    在 Linux 核心中，下列弱點已解決：

    vhost/vsock針對較大的封包使用 kvmalloc/kvfree。 (CVE-2022-50271)

    在 Linux 核心中，下列弱點已解決：

    mm、hugetlb在遞減 h->resv_huge_pages 前取得 hugetlb_lock (CVE-2022-50285)

    在 Linux 核心中，下列弱點已解決：

    kcm註釋 kcm->rx_psock 的資料爭用 (CVE-2022-50291)

    在 Linux 核心中，下列弱點已解決：

    md將 snprintf 取代為 scnprintf (CVE-2022-50299)

    在 Linux 核心中，下列弱點已解決：

    nbd修正訊號中斷時發生的懸置 nbd_start_device_ioctl() (CVE-2022-50314)

    在 Linux 核心中，下列弱點已解決：

    ataahci比對 EM_MAX_SLOTS 和 SATA_PMP_MAX_PORTS (CVE-2022-50315)

    在 Linux 核心中，下列弱點已解決：

    jbd2修正 jbd2_fc_wait_bufs 中的潛在釋放後使用 (CVE-2022-50328)

    在 Linux 核心中，下列弱點已解決：

    cryptocavium - 防止載入韌體的整數溢位 (CVE-2022-50330)

    在 Linux 核心中，下列弱點已解決：

    binder修正 alloc->vma 在與 munmap() 爭用中的 UAF (CVE-2022-50338)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_write_info 中的 null-ptr-deref (CVE-2022-50344)

    在 Linux 核心中，下列弱點已解決：

    nfsd修正錯誤處理路徑中的記憶體洩漏 (CVE-2022-50348)

    在 Linux 核心中，下列弱點已解決：

    nethns修正 hnae_ae_register() 中的潛在記憶體洩漏 (CVE-2022-50352)

    在 Linux 核心中，下列弱點已解決：

    netschedsfb修正 sfb_init() 失敗時的 NULL 指標存取問題 (CVE-2022-50356)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正配額啟用和配額重新掃描 ioctl 之間的爭用 (CVE-2022-50379)

    在 Linux 核心中，下列弱點已解決：

    mm/proc/pid/smaps_rollup修正任何 vma 的 null-deref (CVE-2022-50380)

    在 Linux 核心中，下列弱點已解決：

    net/ieee802154拒絕零大小的 raw_sendmsg() (CVE-2022-50397)

    在 Linux 核心中，下列弱點已解決：

    net如果 sock 無作用請勿存取 sock 在 sk_stream_wait_memory 中的 sk_wq (CVE-2022-50409)

    在 Linux 核心中，下列弱點已解決：

    scsilibsas修正 smp_execute_task_sg() 中的釋放後使用錯誤 (CVE-2022-50422)

    在 Linux 核心中，下列弱點已解決：

    kernfs修正 __kernfs_remove 中的釋放後使用 (CVE-2022-50432)

    在 Linux 核心中，下列弱點已解決：

    ext4避免在 DIO 寫入之後建立內嵌資料時當機 (CVE-2022-50435)

    在 Linux 核心中，下列弱點已解決：

    netschedcake修正 cake_init() 失敗時的 NULL 指標存取問題 (CVE-2022-50452)

    在 Linux 核心中，下列弱點已解決：

    scsi: iscsi: iscsi_tcp呼叫 getpeername() 時修正 null-ptr-deref (CVE-2022-50459)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_flock() 中的 xid 洩漏 (CVE-2022-50460)

    在 Linux 核心中，下列弱點已解決：

    fs/binfmt_elf修正 load_elf_binary() 中的記憶體洩漏 (CVE-2022-50466)

    在 Linux 核心中，下列弱點已解決：

    xhci釋放裝置時從頻寬清單中移除裝置端點 (CVE-2022-50470)

    在 Linux 核心中，下列弱點已解決：

    xen/gntdev容納 VMA 分割 (CVE-2022-50471)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d清理 init_dmars() 錯誤路徑中的 si_domain (CVE-2022-50482)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_fc_record_regions() 中的潛在記憶體洩漏 (CVE-2022-50512)

    在 Linux 核心中，下列弱點已解決：

    tipc修正 tipc_topsrv_kern_subscr 中的資訊洩漏 (CVE-2022-50531)

    在 Linux 核心中，下列弱點已解決：

    usbhostxhci修正 xhci_alloc_stream_info() 中的潛在記憶體洩漏 (CVE-2022-50544)

    在 Linux 核心中，下列弱點已解決：

    tipc修正 tipc_topsrv_accept 中的 null-ptr-deref (CVE-2022-50555)

    在 Linux 核心中，下列弱點已解決：

    xfrm釋放時以 NULL 更新 ipcomp_scratches (CVE-2022-50569)

    在 Linux 核心中，下列弱點已解決：

    arm64ftrace以 mcount 修正模組 PLT (CVE-2022-50579)

    在 Linux 核心中，下列弱點已解決：

    blk-throttle防止在計算等候時間時發生溢位 (CVE-2022-50580)

    在 Linux 核心中，下列弱點已解決：

    Regulatorcore防止整數反向溢位 (CVE-2022-50582)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_fc_record_modified_inode() 中的潛在記憶體洩漏 (CVE-2022-50622)

    在 Linux 核心中，下列弱點已解決：

    mmhugetlb修正 hugetlb_handle_userfault 中的 UAF (CVE-2022-50630)

    在 Linux 核心中，下列弱點已解決：

    mmccore修正移除非標準 SDIO 卡時發生的核心錯誤 (CVE-2022-50640)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_copy_file_range() 中的 xid 洩漏 (CVE-2022-50643)

    在 Linux 核心中，下列弱點已解決：

    RDMA/rxe修正核心 NULL 指標解除參照錯誤 (CVE-2022-50671)

    在 Linux 核心中，下列弱點已解決：

    netrds從 rds_tcp_reset_callbacks() 取消工作時不保留通訊端鎖定 (CVE-2022-50676)

    在 Linux 核心中，下列弱點已解決：

    i40e修正 DMA 對應洩漏 (CVE-2022-50679)

    在 Linux 核心中，下列弱點已解決：

    selinux在 convert_context() 中啟用 GFP_KERNEL 和 GFP_ATOMIC 的使用 (CVE-2022-50699)

    在 Linux 核心中，下列弱點已解決：

    net/ieee802154不警告零大小的 raw_sendmsg() (CVE-2022-50706)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5修正 async 命令介面中可能的釋放後使用 (CVE-2022-50726)

    在 Linux 核心中，下列弱點已解決：

    cryptoakcipher - 設定私密金鑰的預設實作 (CVE-2022-50731)

    在 Linux 核心中，下列弱點已解決：

    usbidmouse修正 idmouse_open 中的 uninit-value (CVE-2022-50733)

    在 Linux 核心中，下列弱點已解決：

    net修正 ops_init() 失敗時nfqnl_nf_hook_drop() 中的 UAF 問題 (CVE-2022-50780)

    在 Linux 核心中，下列弱點已解決：

    ipv6確保通道中的裝置 mtu 正常 (CVE-2022-50816)

    在 Linux 核心中，下列弱點已解決：

    nethsr避免 skb_clone() 中可能的 NULL 解除參照 (CVE-2022-50817)

    在 Linux 核心中，下列弱點已解決：

    jbd2在 fc_do_one_pass() 中新增未命中釋放緩衝區標頭 (CVE-2022-50835)

    在 Linux 核心中，下列弱點已解決：

    jbd2修正潛在的緩衝區標頭參照計數洩漏 (CVE-2022-50839)

    在 Linux 核心中，下列弱點已解決：

    drm/virtio檢查傳輸的 2D BO 是否為 shmem (CVE-2022-50842)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 cifs_ses_add_channel() 中的 xid 洩漏 (CVE-2022-50856)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 VALIDATE_NEGOTIATE_INFO 訊息的錯誤長度 (CVE-2022-50859)

    在 Linux 核心中，下列弱點已解決：

    tcp修正 tcp_add_backlog() 中的帶正負號整數溢位錯誤 (CVE-2022-50865)

    在 Linux 核心中，下列弱點已解決：

    drm防止 drm_copy_field() 嘗試複製 NULL 指標 (CVE-2022-50884)

    據發現，在 Linux 核心中，由於爭用問題，net/sched/sch_api.c 的 qdisc_graft 中存在釋放後使用缺陷。此缺陷可導致拒絕服務問題。(CVE-2023-0590)

    在 Linux 核心的 TUN/TAP 裝置驅動程式功能中發現超出邊界記憶體存取缺陷，該缺陷涉及使用者在啟用 napi frags 時產生惡意網路封包 (過大) 的方式。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2023-3812)

    在 Linux 核心中，下列弱點已解決：

    binder修正 alloc->vma 在與 munmap() 爭用中的 UAF (CVE-2023-54157)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

CentOS Linux 6 主機已安裝的套件會受到 TuxCare CENTOS6：CLSA-2026：1773043650 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network,
    __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at:
    slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398
    __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954
    __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437
    __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized. (CVE-2022-49865)

  - 已解決 Linux 核心中的下列弱點：ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel:
    index 15 is out of range for type 'ahci_em_priv [8]' [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [1.980723] kernel: show_stack+0x52/0x58 [ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f [ 1.980734] kernel:
    dump_stack+0x10/0x12 [ 1.980736] kernel: ubsan_epilogue+0x9/0x45 [ 1.980739] kernel:
    __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci] [1.980748] kernel: ata_qc_issue+0x135/0x240 [ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580 [1.980754] kernel: ? vprintk_default+0x1d/0x20 [ 1.980759] kernel: ata_exec_internal+0x67/0xa0 [ 1.980762] kernel: sata_pmp_read+0x8d/0xc0 [ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90 [ 1.980768] kernel:
    sata_pmp_attach+0x8b/0x310 [ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0 [ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30 [ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci] [1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci] [ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0 [ 1.980795] kernel:
    sata_pmp_eh_recover.isra.0+0x214/0x560 [ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40 [ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci] [ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600 [ 1.980810] kernel: ata_scsi_error+0x9c/0xd0 [ 1.980813] kernel: scsi_error_handler+0xa1/0x180 [ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ? set_kthread_struct+0x50/0x50 [ 1.980826] kernel: ret_from_fork+0x22/0x30 [ 1.980831] kernel: </TASK> This happens because sata_pmp_init_links() initialize link->pmp up to SATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array. I can't find the maximum Enclosure Management ports specified in AHCI spec v1.3.1, but 12.2.1 LED message type states that Port Multiplier Information can utilize 4 bits, which implies it can support up to 16 ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the issue.
    BugLink: https://bugs.launchpad.net/bugs/1970074 (CVE-2022-50315)

  - 已解決 Linux 核心中的下列弱點：binfmt_misc: fix shift-out-of-bounds in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned long, we should define these macros with same type too. (CVE-2022-50497)

  - 已解決 Linux 核心中的下列弱點：netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl. (CVE-2023-52927)

  - 已解決 Linux 核心中的下列弱點：ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:
    dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter] (CVE-2023-53395)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 4.14.301-224.520。因此，會受到 ALAS2-2022-1903 公告中所提及的多個弱點影響。

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。受到此弱點影響的是 IPv6 Handler 元件的 ipv6_renew_options 函式。攻擊者可利用此弱點造成記憶體洩漏。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。
    已爲此弱點指派識別碼 VDB-211021。(CVE-2022-3524)

    在 Linux 核心的邏輯連結控制和適配通訊協定 (L2CAP) 實作中發現釋放後使用缺陷，這是 l2cap_parse_conf_rsp 和 l2cap_parse_conf_req 函式中藍牙堆疊一部分。攻擊者如果在標準藍牙傳輸範圍內具有實體存取權，則在受害者附近時，可以透過藍牙執行程式碼，造成核心記憶體流失。(CVE-2022-42896)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d：修正 dmar_dev_scope_init() 中的 PCI 裝置 refcount 洩漏 (CVE-2022-49002)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正 nilfs_palloc_commit_free_entry() 中的 NULL 指標解除參照 (CVE-2022-49007)

    在 Linux 核心中，下列弱點已解決：

    net：hsr：修復潛在的釋放後使用問題 (CVE-2022-49015)

    在 Linux 核心中，下列弱點已解決：

    net：phy：在 probe() 失敗時修正 null-ptr-deref (CVE-2022-49021)

    在 Linux 核心中，下列弱點已解決：

    btrfs：qgroup：修復 btrfs_qgroup_inherit() 中無效內容錯誤的 Sleep (CVE-2022-49033)

    在 Linux 核心中，下列弱點已解決：

    ntfs：迭代 ATTR_RECORD 時檢查溢位情況 (CVE-2022-49762)

    在 Linux 核心中，下列弱點已解決：

    ntfs：修正 ntfs_attr_find() 中的釋放後使用 (CVE-2022-49763)

    在 Linux 核心中，下列弱點已解決：

    gfs2：讀取超級區塊後檢查 sb_bsize_shift (CVE-2022-49769)

    在 Linux 核心中，下列弱點已解決：

    dm ioctl：修正 list_versions 與模組載入爭用時的錯誤行為 (CVE-2022-49771)

    在 Linux 核心中，下列弱點已解決：

    macvlan：強制執行一致的最小 mtu (CVE-2022-49776)

    在 Linux 核心中，下列弱點已解決：

    mmc：sdhci-pci：修正因缺少 pci_dev_put() 而可能造成的記憶體洩漏 (CVE-2022-49787)

    在 Linux 核心中，下列弱點已解決：

    misc/vmw_vmci：修正 vmci_host_do_receive_datagram() 中的資訊洩漏 (CVE-2022-49788)

    在 Linux 核心中，下列弱點已解決：

    ftrace：修正 ftrace_add_mod() 中的 null 指標解除參照 (CVE-2022-49802)

    在 Linux 核心中，下列弱點已解決：

    drbd：drbd_create_device() 中有釋放後使用錯誤 (CVE-2022-49811)

    在 Linux 核心中，下列弱點已解決：

    kcm：關閉 sk_receive_queue 上的爭用情形 (CVE-2022-49814)

    在 Linux 核心中，下列弱點已解決：

    pinctrl：devicetree：修正 pinctrl_dt_to_map 中的 null 指標解除參照 (CVE-2022-49832)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正重新掛載時 ns_writer 的釋放後使用錯誤 (CVE-2022-49834)

    在 Linux 核心中，下列弱點已解決：

    bpf、test_run：修正 bpf_prog_test_run_skb() 中的對齊問題 (CVE-2022-49840)

    在 Linux 核心中，下列弱點已解決：

    ASoC: core: 修復 snd_soc_exit() 中的釋放後使用問題 (CVE-2022-49842)

    在 Linux 核心中，下列弱點已解決：

    udf：修正 udf_find_entry() 中的 slab-out-of-bounds 寫入錯誤 (CVE-2022-49846)

    在 Linux 核心中，下列弱點已解決：

    nilfs2：修正 nilfs_count_free_blocks() 中的鎖死 (CVE-2022-49850)

    在 Linux 核心中，下列弱點已解決：

    net：macvlan：修正 macvlan_common_newlink 的記憶體洩漏 (CVE-2022-49853)

    在 Linux 核心中，下列弱點已解決：

    tipc：修正 tipc_nl_compat_name_table_dump_header 中的 msg->req tlv len 檢查 (CVE-2022-49862)

    在 Linux 核心中，下列弱點已解決：

    ipv6：addrlabel：修正將結構 ifaddrlblmsg 傳送至網路時的資訊洩漏 (CVE-2022-49865)

    在 Linux 核心中，下列弱點已解決：

    capabilities：修正對 CAP_TO_MASK 進行位移運算時的未定義行為 (CVE-2022-49870)

    在 Linux 核心中，下列弱點已解決：

    net：gso：修正具有混合 head alloc 類型的 frag_list 上的錯誤 (CVE-2022-49872)

    在 Linux 核心中，下列弱點已解決：

    HID：hyperv：修正 mousevsc_probe() 中的潛在記憶體洩漏 (CVE-2022-49874)

    在 Linux 核心 6.0.8 版本中，fs/ntfs/attrib.c 的 ntfs_attr_find 中有超出邊界讀取情形。
    (CVE-2023-26607)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - ipv6： addrlabel：修正將 struct ifaddrlblmsg 傳送到網路時的資訊洩露 將「struct ifaddrlblmsg」複製到網路時，__ifal_reserved保持未初始化狀態，導致 1 位元組的資訊洩露： 錯誤：
    KMSAN：__netdev_start_xmit中的 kernel-network-infoleak ./include/linux/netdevice.h：4841 __netdev_start_xmit ./include/linux/netdevice.h：4841 netdev_start_xmit ./include/linux/netdevice.h：4857 xmit_one net/core/dev.c：3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c：3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c：4256 dev_queue_xmit ./include/linux/netdevice.h：3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c：307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c：325 netlink_deliver_tap net/netlink/af_netlink.c：338 __netlink_sendskb net/netlink/af_netlink.c：1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c：1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c：1360 nlmsg_unicast ./include/net/netlink.h：1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c：758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c：628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c：6082 ... Uninit 是在以下位置建立的：
    slab_post_alloc_hook+0x118/0xb00 mm/slab.h：742 slab_alloc_node mm/slub.c：3398
    __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c：3437 __do_kmalloc_node mm/slab_common.c：954
    __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c：975 kmalloc_reserve net/core/skbuff.c：437
    __alloc_skb+0x27a/0xab0 net/core/skbuff.c：509 alloc_skb ./include/linux/skbuff.h：1267 nlmsg_new ./include/net/netlink.h：964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c：608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c：6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c：2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c：6109 netlink_unicast_kernel net/netlink/af_netlink.c：1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c：1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c：1921 ... 此修補程式可確保保留欄位一律初始化。（CVE-2022-49865）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

ID	名稱	產品	系列	已發布	已更新	嚴重性
360928	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點（CENTOS8.5：CLSA-2026：1771077729）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/18	high
361173	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.4：CLSA-2026：1771078945）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
362062	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個弱點（CENTOS7：CLSA-2026：1778756832）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
168507	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。15-2022-011 (ALASKERNEL-5.15-2022-011)	Nessus	Amazon Linux Local Security Checks	2022/12/8	2026/2/9	high
200364	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。4-2024-071（ALASKERNEL-5。4-2024-071	Nessus	Amazon Linux Local Security Checks	2024/6/11	2026/6/4	high
168520	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-023 (ALASKERNEL-5.10-2022-023)	Nessus	Amazon Linux Local Security Checks	2022/12/8	2026/2/11	high
359745	CentOS Linux 6 [TuxCare] 安全性更新：核心 / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc 多個弱點（CENTOS6：CLSA-2026：1773043650）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
168676	Amazon Linux 2：核心 (ALAS-2022-1903)	Nessus	Amazon Linux Local Security Checks	2022/12/13	2026/2/24	high
247681	Linux Distros 未修補弱點：CVE-2022-49865	Nessus	Misc.	2025/8/10	2026/11/5	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high

high