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

  - 追踪移除已使用的動態事件時釋放緩衝區。新增和移除 65536 個動態事件之後事件的類型欄位將使用第一個可用的類型數 (其他事件目前未使用)。類型編號是追踪環緩衝區 (稱為事件) 中二進位 blob 的識別碼以將其對應至可剖析二進位 blob 的邏輯。問題在於如果追踪到某個動態事件 (例如 kprobe 事件) 且該事件位於環緩衝區中之後該事件會遭到移除 (因為它是動態的也就是說可以建立和銷毀該事件)所建立的檔案編號相同因此在剖析二進位 blob 時將使用新事件的邏輯。為了說明此問題為何會成為問題以致於下列可使核心損毀的版本# cd /sys/kernel/tracing # for i in `seq 65536` do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # 完成上述的每次重複寫入至 kprobe_events 的作業都會移除舊事件並建立新事件 (使用相同格式)並增加類型編號到下一個可用的類型編號直到類型編號超過 65535這是 16 位元類型的最大編號。達到該號碼後，配置新號碼的邏輯只會尋找下一個可用的號碼。移除動態事件時該數字可供下一個建立的動態事件重複使用。也就是說，一旦上述項目達到數量上限，則指派給該迴圈中事件的數量將保持不變。現在這表示刪除動態事件並建立另一個動態事件時將會重複使用先前的事件類型編號。這就是可能發生不良情況的地方。在上述迴圈結束後會將 do_sys_openat2 函式呼叫的第一個參數讀取為整數的 kprobes/foo 事件。 # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] ....
    2007.849603foo (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620foo
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838foo
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880foo
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable 現在如果我們刪除 kprobes/foo/enable 現在如果我們刪除 kprobe並建立新的 kprobes 來讀取字串# echo 'p:kprobes/foo do_sys_openat2 +0($arg2 ):string' > kprobe_events現在我們可以追踪 # cat trace sendmail-1942 [002] ..... 530.136320foo
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817foo (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961foo (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278foo (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563foo (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

請注意，Nessus 依賴供應商報告的套件存在。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2025：1749480611 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已解決 Linux 核心中的下列弱點：net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below:
    ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422#0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:
    <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done.
    (CVE-2022-49014)

  - 已解決 Linux 核心中的下列弱點：hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().
    (CVE-2022-49029)

  - 已解決 Linux 核心中的下列弱點：drm/i915: Fix potential bit_17 double-free A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. [tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) (CVE-2023-52930)

  - 已解決 Linux 核心中的下列弱點：cifs: fix session state check in reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

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

CentOS Linux 8 主機安裝的套件受到 TuxCare CENTOS-STREAM8：CLSA-2026：1783790425 公告中提及的多個弱點影響。

  - netfilter 中的缺陷可讓連線攻擊者推斷 openvpn 連線端點資訊，以便進一步使用這些資訊發動傳統網路攻擊。(CVE-2021-3773)

  - 在代理虛擬化 TPM 裝置的 Linux 核心實作中發現缺陷。在已設定虛擬化 TPM 裝置的系統上 (非預設設定)，本機攻擊者可建立釋放後使用情形，並造成可在系統上提升權限的狀況。 (CVE-2022-2977)

  - 已解決 Linux 核心中的下列弱點：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已解決 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)

  - 已解決 Linux 核心中的下列弱點：ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null.
    When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
    ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120
    __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path. (CVE-2022-49826)

請注意，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.162-141.675。因此，會受到 ALAS2KERNEL-510-2023-025 公告中所提及的多個弱點影響。

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

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

    來賓可透過 netback 觸發 NIC 介面重設/中止/損毀。來賓可透過傳送特定類型的封包，在 Linux 型網路後端觸發 NIC 介面重設/中止/損毀。Linux 網路堆疊的其餘部分似乎有一個 (未寫入的) 假設，即封包通訊協定標頭都包含在 SKB 的線性區段中，如果不是這樣，則某些 NIC 會出現不良行為。據報告，Cisco (enic) 和 Broadcom NetXtrem II BCM5780 (bnx2x) 會發生此問題，但其他 NIC/驅動程式也可能有此問題。如果前端傳送具有分割標頭的要求，netback 會將違反上述假設的要求轉送至網路核心，進而導致上述錯誤行為。(CVE-2022-3643)

    來賓可在 Linux netback 驅動程式中觸發鎖死 [此 CNA 資訊記錄與多個 CVE 有關；
    文字說明了哪些方面/弱點對應於哪個 CVE。] XSA-392 的修補程式引入了另一個問題，當嘗試釋放因 XSA-392 處理而丟棄的 SKB 時，可能會導致鎖死 (CVE-2022-42328)。此外，當因其他原因中斷套件時，如果在 xen-netback 驅動程式所連線的介面中，netpoll 處於作用中，則可能會發生相同的鎖死情況 (CVE-2022-42329)。(CVE-2022-42328)

    來賓可在 Linux netback 驅動程式中觸發鎖死 [此 CNA 資訊記錄與多個 CVE 有關；
    文字說明了哪些方面/弱點對應於哪個 CVE。] XSA-392 的修補程式引入了另一個問題，當嘗試釋放因 XSA-392 處理而丟棄的 SKB 時，可能會導致鎖死 (CVE-2022-42328)。此外，當因其他原因中斷套件時，如果在 xen-netback 驅動程式所連線的介面中，netpoll 處於作用中，則可能會發生相同的鎖死情況 (CVE-2022-42329)。(CVE-2022-42329)

    在 Linux 核心的 SYSCTL 子系統中，在使用者變更特定核心參數和變數的方式中發現堆疊溢位缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-4378)

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

    udf：修正間接範圍邊界的預先配置捨棄 (CVE-2022-48946)

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

    igb：初始化信箱訊息以進行 VF 重設 (CVE-2022-48949)

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

    ipv6：避免 ip6_fragment() 中的釋放後使用 (CVE-2022-48956)

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

    xen-netfront：修正即時移轉後的 NULL sring (CVE-2022-48969)

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

    af_unix：從 unix_diag_get_exact() 中的 in_skb 取得 user_ns。 (CVE-2022-48970)

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

    mac802154：修正 ieee802154_if_add() 中遺漏的 INIT_LIST_HEAD (CVE-2022-48972)

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

    can：af_can：修正 can_rcv_filter 中的 Null 指標解除參照弱點 (CVE-2022-48977)

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

    HID：核心：修正 hid_report_raw_event 中的 shift-out-of-bounds (CVE-2022-48978)

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

    drm/shmem-helper：移除放置在錯誤路徑中的 errant (CVE-2022-48981)

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

    mm/gup：修正 dax 的 gup_pud_range() (CVE-2022-48986)

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

    media：v4l2-dv-timings.c：修正過於嚴格的空白健全性測試 (CVE-2022-48987)

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

    memcg：修正 memcg_write_event_control() 中可能的釋放後使用 (CVE-2022-48988)

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

    mm/khugepaged：叫用 shmem/file 折疊路徑中的 MMU 通知程式 (CVE-2022-48991)

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

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

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

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

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

    ommu/vt-d：修正 has_external_pci() 中的 PCI 裝置 refcount 洩漏 (CVE-2022-49000)

    在 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 核心中，下列弱點已解決 :

    tipc：在 tipc_msg_validate 之後重新擷取 skb cb (CVE-2022-49017)

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

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

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

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

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

    iavf：修正 iavf_init_module() 中的錯誤處理 (CVE-2022-49027)

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

    ixgbevf：修正 ixgbevf_init_module() 中的資源洩漏 (CVE-2022-49028)

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

    libbpf：處理 ringbuf mmap 的大小溢位 (CVE-2022-49030)

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

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

    在 Linux 核心的 5.6 至 5.11 版 (含) 中，io_uring 子系統的 IORING_OP_CLOSE 作業存在檢查時間與使用時間不一致的問題，使得本機使用者可以將其特權提升為 root 特權。
    此問題在 b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb 中引入，然後在 9eac1904d3364254d622bf2c771c4f85cd435fc2 中修補，並在 788d0824269bef539fe31a785b1517882eafed93 中反向移植至穩定版。(CVE-2023-1295)

    在 Linux 核心中 net/can/af_can.c 的 can 通訊協定中發現 Null 指標解除參照問題。
    在 CAN 框架的接收路徑中，ml_priv 可能未初始化。本機使用者可利用此問題造成系統當機或造成拒絕服務。(CVE-2023-2166)

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

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

遠端 Oracle Linux 9 主機中安裝的套件受到 ELSA-2025-6966 公告中提及的多個弱點影響。

    - netstmmacdwmac-tegra從裝置樹狀結構讀取 iommu 資料流 id (Izabela Bakollari) [RHEL-75649] {CVE-2025-21663}
    - netstmmac停用 tc cbs 時修正除零錯誤 (Izabela Bakollari) [RHEL-63931] {CVE-2024-49977}
    - scsiqla2xxx修正卸載時的釋放後使用 (Ewan D. Milne) [RHEL-75828] {CVE-2024-56623}

Tenable 已直接從 Oracle Linux 安全公告擷取前置描述區塊。

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

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

  - 已解決 Linux 核心中的下列弱點：media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - 已解決 Linux 核心中的下列弱點：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

  - 已解決 Linux 核心中的下列弱點：scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. (CVE-2022-48791)

  - 已解決 Linux 核心中的下列弱點：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已解決 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)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
225798	Linux Distros 未修補的弱點：CVE-2022-49006	Nessus	Misc.	2025/3/5	2026/7/17	high
282947	MiracleLinux 9kernel-5.14.0-570.12.1.el9_6 (AXSA:2025-10392:38)	Nessus	Miracle Linux Local Security Checks	2026/1/13	2026/1/20	critical
170458	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。15-2023-012（ALASKERNEL-5。15-2023-012	Nessus	Amazon Linux Local Security Checks	2023/1/24	2026/6/4	high
361420	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2025：1749480611）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	high
237324	RHEL 9：核心 (RHSA-2025:6966)	Nessus	Red Hat Local Security Checks	2025/5/27	2025/10/28	critical
352893	CentOS Linux 8 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個漏洞（CENTOS-STREAM8：CLSA-2026：1783790425）	Nessus	CentOS Local Security Checks	2026/9/30	2026/10/1	critical
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
170472	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2023-025)	Nessus	Amazon Linux Local Security Checks	2023/1/24	2026/2/26	high
237030	Oracle Linux 9：核心 (ELSA-2025-6966)	Nessus	Oracle Linux Local Security Checks	2025/5/22	2026/2/9	critical
353232	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high

偵測

搜尋 Plugin

high

critical

high

high

critical

critical

high

high

critical

high