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

  - iommu/vt-d清理 init_dmars() 錯誤路徑中的 si_domain。發生失敗時可以在提交 ee2653bbe89d 之前的核心中發現一個從 kmem_cache_destroy() 噴濺出來的內容 (iommu/vt-d移除網域和 devinfo mempool)在 init_dmars() 中因為 iommu_domain 快取仍有物件。雖然 mempool 程式碼現已消失但如果 init_dmars() 失敗仍會洩漏 si_domain 記憶體。因此請清理 init_dmars() 錯誤路徑中的 si_domain。 (CVE-2022-50482)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/ksm: fix race with VMA iteration and mm_struct teardown exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode. Ensure that the maple tree is still valid by checking ksm_test_exit() after taking the mmap_lock in read mode, but before the for_each_vma() iterator dereferences a destroyed maple tree. Since the maple tree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator to avoid dereferencing a maple tree without the external lock flag, which would create a lockdep warning. (CVE-2023-53614)

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

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

  - wifiiwlwifimvm不信任韌體 n_channels如果韌體傳送給我們一個損毀的 MCC 回應其中的 n_channels 比命令回應的數量大很多我們可能會復製過多 (未初始化) 記憶體甚至在 n_channels 為大到足以使其耗盡為 FW 回應所配置的一頁。透過檢查長度來修正該問題。執行 < 比較已足夠但韌體應正確執行因此檢查更嚴格。 (CVE-2023-53589)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns
    -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
    (CVE-2022-50490)

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

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

  - cifs釋放命中 fscache 讀取時的作品集鎖定。在目前的程式碼下當呼叫 cifs_readpage_worker 時呼叫協定是被呼叫者應解除鎖定該頁面。這在 Documentation/filesystems/vfs.rst 的 read_folio 區段中記錄如下 > 無論讀取成功與否一旦完成檔案系統皆應解除鎖定該作品集。若無此變更則當 fscache 正在使用中且在讀取期間發生快取命中時會洩漏頁面鎖定進而在後續的頁面讀取 (透過 mmap) 中產生下列堆疊$ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault +0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 這需要重新開機才能解決這是鎖死。但請注意cifs_readpage_from_fscache 呼叫會將頁面標記為乾淨但不會釋放 folio 鎖定。成功時這會在 __cifs_readpage_from_fscache 中發生。不過此時釋出鎖定並不適合因為 cifs_readahead 也會呼叫 cifs_readpage_from_fscache而 *會* 在鎖定傳回後無條件釋放鎖定。因此此變更可有效使 cifs_readpage_worker 像 cifs_readahead 一樣運作。 (CVE-2023-53593)

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

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

  - spiqup不略過移除錯誤路徑中的清理在平台驅動程式的移除回呼中提早傳回是錯誤的。在此情況下錯誤路徑中的 dma 資源不會釋放。之後不會再重試因此這是永久性洩漏。若要修正此問題請只在喚醒裝置失敗時略過硬體停用。
    (CVE-2023-53567)

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

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

  - ntb_netdev在中斷內容中使用 dev_kfree_skb_any()當個別 DMA 作業完成時可以在中斷內容中透過 DMA 架構呼叫 TX/RX 回呼處置程式 (ntb_netdev_tx_handler()、ntb_netdev_rx_handler())。因此這些常式發出的任何呼叫釋放 skb 都應使用中斷內容安全的 dev_kfree_skb_any() 函式。之前這些回呼處置程式會呼叫 dev_kfree_skb() 的中斷不安全版本。這並未在 Intel IOAT DMA 引擎上出現問題因為該驅動程式使用 tasklet而非硬中斷處置程式 (例如 AMD PTDMA DMA 驅動程式)。在 AMD 系統上遇到核心警告訊息由於 in_hardirq() 為 true因此該訊息是從 skb_release_head_state() 發出。除了核心中使用者可見警告此錯誤的另一個徵兆是整個 ntb_netdev 介面的 TCP/IP 效能非常差即比預期低大約一個數量級。在使用 dev_kfree_skb_any() 進行修復之後skb_release_head_state() 的核心警告會停止且 TCP/IP 效能 (以 iperf 衡量) 與預期結果相當在 AMD Milan 型伺服器上約為 20 Gb/s。請注意此效能可與 Intel 型伺服器相提並論。 (CVE-2022-50476)

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

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

  - scsiqla2xxx修正刪除爭用情形使用除錯核心時連結清單損毀所導致的系統當機。連結清單損毀的原因是因為工作階段刪除被允許排入佇列兩次。以下是顯示允許相同連接埠在不同 cpu 上雙重佇列刪除的內部追踪。 20808683956 015 qla2xxx [0000:13:00.1]-e801:4︰排程 sess ffff93ebf9306800 以刪除 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [00001:13:000]-e8000。 4為刪除 50:06:0e:80:12:48:ff:50 fc4_type 1 排程 sess ffff93ebf9306800 移動已刪除旗標鎖定的清除/設定。 (CVE-2023-53615)

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

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

  - 已解決 Linux 核心中的下列弱點：USB: Gadget: core: Help prevent panic during UVC unconfigure Avichal Rakesh reported a kernel panic that occurred when the UVC gadget driver was removed from a gadget's configuration. The panic involves a somewhat complicated interaction between the kernel driver and a userspace component (as described in the Link tag below), but the analysis did make one thing clear: The Gadget core should accomodate gadget drivers calling usb_gadget_deactivate() as part of their unbind procedure. Currently this doesn't work. gadget_unbind_driver() calls driver->unbind() while holding the udc->connect_lock mutex, and usb_gadget_deactivate() attempts to acquire that mutex, which will result in a deadlock. The simple fix is for gadget_unbind_driver() to release the mutex when invoking the ->unbind() callback. There is no particular reason for it to be holding the mutex at that time, and the mutex isn't held while the ->bind() callback is invoked. So we'll drop the mutex before performing the unbind callback and reacquire it afterward. We'll also add a couple of comments to usb_gadget_activate() and usb_gadget_deactivate(). Because they run in process context they must not be called from a gadget driver's ->disconnect() callback, which (according to the kerneldoc for struct usb_gadget_driver in include/linux/usb/gadget.h) may run in interrupt context. This may help prevent similar bugs from arising in the future. (CVE-2023-53580)

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

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

  - 已解決 Linux 核心中的下列弱點：iommu/s390: Fix memory corruption when using identity domain zpci_get_iommu_ctrs() returns counter information to be reported as part of device statistics; these counters are stored as part of the s390_domain. The problem, however, is that the identity domain is not backed by an s390_domain and so the conversion via to_s390_domain() yields a bad address that is zero'd initially and read on-demand later via a sysfs read. These counters aren't necessary for the identity domain; just return NULL in this case. This issue was discovered via KASAN with reports that look like: BUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device when using the identity domain for a device on s390. (CVE-2025-39939)

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

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

  - 已解決 Linux 核心中的下列弱點：tunnels: fix kasan splat when generating ipv4 pmtu error If we try to emit an icmp error in response to a nonliner skb, we get BUG:
    KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220 Read of size 4 at addr ffff88811c50db00 by task iperf3/1691 CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309 [..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..] ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.
    After this change, splat is gone and iperf3 is no longer stuck. (CVE-2023-53600)

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

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

  - 已解決 Linux 核心中的下列弱點：octeontx2-pf: mcs: Fix NULL pointer dereferences When system is rebooted after creating macsec interface below NULL pointer dereference crashes occurred. This patch fixes those crashes by using correct order of teardown [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 3324.415726] Mem abort info: [ 3324.418510] ESR = 0x96000006 [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits [3324.426865] SET = 0, FnV = 0 [ 3324.429913] EA = 0, S1PTW = 0 [ 3324.433047] Data abort info: [3324.435921] ISV = 0, ISS = 0x00000006 [ 3324.439748] CM = 0, WnR = 0 .... [ 3324.575915] Call trace: [3324.578353] cn10k_mdo_del_secy+0x24/0x180 [ 3324.582440] macsec_common_dellink+0xec/0x120 [ 3324.586788] macsec_notify+0x17c/0x1c0 [ 3324.590529] raw_notifier_call_chain+0x50/0x70 [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c [ 3324.599921] rollback_registered_many+0x354/0x5bc [ 3324.604616] unregister_netdevice_queue+0x88/0x10c [ 3324.609399] unregister_netdev+0x20/0x30 [ 3324.613313] otx2_remove+0x8c/0x310 [ 3324.616794] pci_device_shutdown+0x30/0x70 [ 3324.620882] device_shutdown+0x11c/0x204 [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 966.673712] Mem abort info: [ 966.676497] ESR = 0x96000006 [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits [ 966.684848] SET = 0, FnV = 0 [ 966.687895] EA = 0, S1PTW = 0 [966.691028] Data abort info: [ 966.693900] ISV = 0, ISS = 0x00000006 [ 966.697729] CM = 0, WnR = 0 [966.833467] Call trace: [ 966.835904] cn10k_mdo_stop+0x20/0xa0 [ 966.839557] macsec_dev_stop+0xe8/0x11c [966.843384] __dev_close_many+0xbc/0x140 [ 966.847298] dev_close_many+0x84/0x120 [ 966.851039] rollback_registered_many+0x114/0x5bc [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0 [966.860952] unregister_netdevice_many+0x18/0x24 [ 966.865560] macsec_notify+0x1ac/0x1c0 [ 966.869303] raw_notifier_call_chain+0x50/0x70 [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c [ 966.878694] rollback_registered_many+0x354/0x5bc [ 966.883390] unregister_netdevice_queue+0x88/0x10c [ 966.888173] unregister_netdev+0x20/0x30 [ 966.892090] otx2_remove+0x8c/0x310 [ 966.895571] pci_device_shutdown+0x30/0x70 [ 966.899660] device_shutdown+0x11c/0x204 [ 966.903574]
    __do_sys_reboot+0x208/0x290 [ 966.907487] __arm64_sys_reboot+0x20/0x30 [ 966.911489] el0_svc_handler+0x80/0x1c0 [ 966.915316] el0_svc+0x8/0x180 [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060) [ 966.924448] ---[ end trace 341778e799c3d8d7 ]--- (CVE-2023-53595)

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

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

  - ip_vti修正 decode_session6 中潛在的 slab-use-after-free 問題。ip_vti 裝置設為 sfb 類型的 qdisc 時所傳送的 skb 的 cb 欄位可能會在加入佇列期間遭到修改。則 ip_vti 裝置傳送 IPv6 封包時可能會發生 slab-use-after-free。當提交 f855691975bb (xfrm6修正
    _decode_session6.) 所示xfrm_decode_session 原本預定僅供接收路徑使用。
    傳輸期間未設定 IP6CB(skb)->nhoff。因此請在傳送封包之前將 skb 中的 cb 欄位設為 0。 (CVE-2023-53559)

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

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

  - 已解決 Linux 核心中的下列弱點：dax: Fix dax_mapping_release() use after free A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region provider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232
    __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: <TASK> [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150 Due to attempting ida_free() on an ida object that has already been freed. Devices typically only hold a reference on their parent while registered. If a child needs a parent object to complete its release it needs to hold a reference that it drops from its release callback.
    Arrange for a dax_mapping to pin its parent dev_dax instance until dax_mapping_release(). (CVE-2023-53613)

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

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

  - 已解決 Linux 核心中的下列弱點：bonding: do not assume skb mac_header is set Drivers must not assume in their ndo_start_xmit() that skbs have their mac_header set. skb->data is all what is needed. bonding seems to be one of the last offender as caught by syzbot: WARNING: CPU: 1 PID:
    12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline] WARNING: CPU:
    1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470 Modules linked in: CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline] RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline] RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline] RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline] RIP:
    0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline] RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline] RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470 Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283 RAX: ffffffff835874db RBX:
    000000000000ffff RCX: 0000000000040000 RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6 RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584 R10: 0000000000000007 R11:
    ffff8881599fc780 R12: ffff88811b6a7b7e R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76 FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> [<ffffffff8471a49f>] netdev_start_xmit include/linux/netdevice.h:4925 [inline] [<ffffffff8471a49f>] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380 [<ffffffff851d845b>] dev_direct_xmit include/linux/netdevice.h:3043 [inline] [<ffffffff851d845b>] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284 [<ffffffff851c7472>] packet_snd net/packet/af_packet.c:3112 [inline] [<ffffffff851c7472>] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143 [<ffffffff8467a4b2>] sock_sendmsg_nosec net/socket.c:716 [inline] [<ffffffff8467a4b2>] sock_sendmsg net/socket.c:736 [inline] [<ffffffff8467a4b2>] __sys_sendto+0x472/0x5f0 net/socket.c:2139 [<ffffffff8467a715>] __do_sys_sendto net/socket.c:2151 [inline] [<ffffffff8467a715>]
    __se_sys_sendto net/socket.c:2147 [inline] [<ffffffff8467a715>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147 [<ffffffff8553071f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff8553071f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80 [<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-53601)

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

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

  - netethernetti修正 netcp_ndo_start_xmit() 的傳回類型 透過 clang 的核心控制流程完整性 (kCFI、CONFIG_CFI_CLANG)可針對預期的函式指標原型驗證間接呼叫目標以確保呼叫目標有效有助於減輕 ROP 攻擊。如果不同則執行時會發生失敗其表現形式為核心錯誤或執行緒遭到終止。clang 中的一個建議警告旨在於編譯時擷取這些警告其顯示：
    drivers/net/ethernet/ti/netcp_core.c:1944:21錯誤初始化「netdev_tx_t (*)(struct sk_buff *, struct net_device *)」(即「enum netdev_tx (*)(struct sk_buff *)) 的不相容函式指標類型struct net_device *)') 具有 'int (struct sk_buff *, struct net_device *)' 類型的運算式 [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netcp_ndo_start_xmit^~~~~ ~~~~ ~ ~ ~ ~ 產生 1 個錯誤。 ->struct net_device_ops 中的 ndo_start_xmit() 預期傳回類型為「netdev_tx_t」而非「int」。調整 netcp_ndo_start_xmit() 的傳回類型以符合原型的 以解決警告和 CFI 失敗。 (CVE-2022-50486)

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

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

  - powerpc/rtas避免在 rtas_os_term() 中排程。在 rtas_os_term() 中使用 rtas_busy_delay() 處理 ibm,os-term RTAS 函式的忙碌狀態是不安全的行為核心錯誤 - 未同步：已嘗試終止 initexitcode=0x0000000b 錯誤從 arch/powerpc/kernel/rtas.c:618 的無效內容呼叫休眠函式 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2預期 0 CPU7 PID1 通訊swapper/0 受污染的 GD 6.0.0-rc5-02182-gf8553a572277-dirty #9 呼叫追踪 [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (不可靠) [c000000007bf8f800000000] ] [c0000000002440e4] __might_resched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+ 0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] make_task _dead+0xdc/0x200 改用 rtas_busy_delay_time()其會發出是否再次嘗試 ibm,os-term RTAS 呼叫的訊號而不會產生副作用。 (CVE-2022-50504)

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

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

  - dm cache修正 destroy() 中的 UAF 當 dm_resume() 和 dm_destroy() 為並行時Dm_cache 也有相同的 UAF 問題。因此在 destroy() 中再次取消計時器。 (CVE-2022-50496)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915: Make intel_get_crtc_new_encoder() less oopsy The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that.
    (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c) (CVE-2023-53571)

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

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

  - hwmon(coretemp) 非常規簡化平台裝置處理 Coretemp 的平台驅動程式。所有實際工作皆由 initcall 和 CPU 熱插拔通知程式全域完成而驅動程式只會在驅動程式核心的冗長來回行程中有效地包裝 hwmon 介面的配置和註冊。動態建立和破壞平台裝置以啟動和關閉介面的整個邏輯容易出錯因為它假設 platform_device_add() 會在傳回前同步系結驅動程式並設定 drvdata因此如果 drivers_autoprobe 關閉則會導致 NULL 解除參照適用於平台匯流排。此外異常方式從 CPU 熱插拔通知程式 (已在程式碼中註解其會鎖死暫停)也會造成 lockdep 問題其可能想要從平台匯流排通知程式合法註冊 CPU 熱插拔通知程式。解決所有這些問題的方法是完全移除此異常行為、將平台裝置與模組本身的存留期系結在一起並從熱插拔通知程式直接管理 hwmon 介面。有輕微的使用者可見變更即 /sys/bus/platform/drivers/coretemp 將不再出現且 /sys/devices/platform/coretemp.n 將保持存在 (熱插拔套件 n)但 hwmon 使用者應實際上只會尋找其行為維持不變的 hwmon 介面是否存在。 (CVE-2023-53612)

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

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

  - 已解決 Linux 核心中的下列弱點：bus: mhi: host: Range check CHDBOFF and ERDBOFF If the value read from the CHDBOFF and ERDBOFF registers is outside the range of the MHI register space then an invalid address might be computed which later causes a kernel panic. Range check the read value to prevent a crash due to bad data from the device. (CVE-2023-53598)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: ipset: Rework long task execution when adding/deleting entries When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba (netfilter: ipset: Limit the maximal range of consecutive elements to add/delete) tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel. (CVE-2023-53549)

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

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

  - 已解決 Linux 核心中的下列弱點：rtc: class: Fix potential memleak in devm_rtc_allocate_device() devm_rtc_allocate_device() will alloc a rtc_device first, and then run dev_set_name(). If dev_set_name() failed, the rtc_device will memleak. Move devm_add_action_or_reset() in front of dev_set_name() to prevent memleak. unreferenced object 0xffff888110a53000 (size 2048): comm python3, pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0...... 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............
    backtrace: [<000000004aac0364>] kmalloc_trace+0x21/0x110 [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400 [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80 [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581] [<00000000f0eba0ae>] spi_probe+0xde/0x130 [<00000000bff89ee8>] really_probe+0x175/0x3f0 [<00000000128e8d84>] __driver_probe_device+0xe6/0x170 [<00000000ee5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store+0x49/0x70 [<000000008139c323>] sysfs_kf_write+0x8d/0xb0 [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0 [<00000000ecbe3895>] vfs_write+0x61a/0x7d0 [<00000000aa2196ea>] ksys_write+0xc8/0x190 [<0000000046a600f5>] do_syscall_64+0x37/0x90 [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50477)

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

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

  - scsi目標修正多個 LUN_RESET 處理這修正了啟動器認為 LUN_RESET 已清除執行中命令但其實並沒有清除的錯誤。此錯誤已在認可 51ec502a3266 中新增 (目標在處理前從清單中刪除 tmr)。在下列情況下會發生此問題 1. NI/O cmds 正在分散於 2 個工作階段的目標層中執行。 2. 啟動器會針對每個工作階段傳送一個 LUN_RESET。 3. session1 的 LUN_RESET 會針對兩個工作階段的所有執行中命令進行迴圈並將這些命令移至其本機 Drain_task_list。 4.
    session2 的 LUN_RESET 看不到來自 session1 的 LUN_RESET因為上述認可已使其自行移除。 session2 也看不到任何命令因為其他重設將其移出狀態清單。 5.
    session2 的 LUN_RESET 之後將會完成並提供成功的回應。 6. session2 的 inititor 認為其工作階段上執行的命令現在已因成功回應而遭到清除因此會清除其工作階段執行中的命令。然後會重新啟動它們。 7. 命令最終會在後端完成且目標開始傳回這些命令的中止工作狀態。如果 ITT 已重新配置啟動器將會擲回無效的 ITT 錯誤或可能意外查閱新工作。透過還原修補程式修正錯誤并序列化 LUN_RESETs 與先佔與中止的執行。也防止我們在 core_tmr_drain_tmr_list 中的 LUN_RESET 上等待因為原始修補程式已修正一個未提及的錯誤。針對 LUN_RESET1 core_tmr_drain_tmr_list 可以查看第二個 LUN_RESET並在其上等待。然後第二個重設會執行 core_tmr_drain_tmr_list 並查看第一個重設並在其上等待進而導致鎖死。 (CVE-2023-53586)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core:
    sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb:
    ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver:
    ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets.
    A new UDP socket is created in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only added in udp_lib_get_port() which happens when a socket is bound. When bpf_sk_assign was added it wasn't possible to access unhashed UDP sockets from BPF, so this wasn't a problem. This changed in commit 0c48eefae712 (sock_map: Lift socket state restriction for datagram sockets), but the helper wasn't adjusted accordingly. The following sequence of events will therefore lead to a refcount leak: 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap. 2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount. 3. bind() or connect() the socket, setting SOCK_RCU_FREE. 4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE. 5. tcp_v4_rcv() skips sock_put(). Fix the problem by rejecting unhashed sockets in bpf_sk_assign(). This matches the behaviour of __inet_lookup_skb which is ultimately the goal of bpf_sk_assign(). (CVE-2023-53585)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580) (CVE-2023-53552)

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

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

  - binfmt_misc修正 check_special_flags 中的 shift-out-of-bounds UBSAN 報告一個 shift-out-of-bounds 警告
    無法在「int」類型呼叫追踪中表示由 1 左移 31 位 <TASK> __dump_stack lib/dump_stack.c:88 [內嵌] 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 [內嵌] create_entry fs/binfmt_misc.c:456 [內嵌] bm_register_write+0x9d3/0xa20 fs/binfmt_misc. 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 [內嵌] do_syscall_64+0x34/0x80 arch/x86/entry /common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 由於節點的旗標類型是不帶正負號的長整數因此我們也應該以相同的類型定義這些巨集。 (CVE-2022-50497)

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

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

  - 已解決 Linux 核心中的下列弱點：RDMA/core: Make sure ib_port is valid when access sysfs node The ib_port structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr :
    port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27:
    ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18:
    0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 :
    0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 :
    ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8
    __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861) (CVE-2022-50475)

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

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

  - 已解決 Linux 核心中的下列弱點：vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs.
    (CVE-2023-53543)

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

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

  - ALSAusb-audio修正潛在的記憶體洩漏。當驅動程式在配置 URB 或緩衝區時命中 -ENOMEM 時會中止並轉至釋放所有先前配置資源的錯誤路徑。但是，當
    -ENOMEM 在同步 EP URB 配置迴圈中間命中可能會留下未釋放的部分配置 URB因為 ep->nurbs 在該點仍為零。修正方法是先設定 ep->nurbs讓錯誤處置程式在完整的 URB 清單上循環。 (CVE-2022-50484)

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

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

  - netwwaniosm修正移除裝置時的 NULL 指標解除參照。在暫停與恢復的周期中裝置的移除和重新掃描最後會發生 NULL 指標解除參照。在驅動程式初始化期間如果 ipc_imem_wwan_channel_init() 無法取得有效的裝置功能它會傳回錯誤且進一步不會配置資源 (wwan struct)。現在在此情況下如果啟動驅動程式移除程序則會導致 NULL 指標例外狀況因為未配置的 wwan 結構已在 ipc_wwan_deinit() 內解除參照。 ipc_imem_run_state_worker() 處理已叫用的函式傳回值並在失敗時釋放資源。它也會報告失敗時的連結故障事件。使用者空間應用程式可處理此事件以重設裝置進而還原裝置通訊。
    (CVE-2023-53561)

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

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

  - 已解決 Linux 核心中的下列弱點：fprobe: Release rethook after the ftrace_ops is unregistered While running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: <TASK> fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc </TASK> In unregister_fprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu.
    Moving rethook_free call after fp->ops is unregistered with unregister_ftrace_function call.
    (CVE-2023-53557)

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

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

  - netbcmgenet新增過大封包的檢查偶爾我們可能會收到來自硬體的過大封包這超出了我們配置 SKB 所用的標稱 2KiB 緩衝區大小。新增中斷封包的早期檢查以避免叫用 skb_over_panic()並繼續處理下一個封包。 (CVE-2023-53535)

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

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

  - ring-buffer在緩衝區損毀前同步 IRQ 運作如果在損毀前將某些內容寫入緩衝區則可能 (在真正的系統中不會發生這種情況在 ARCH=um 的時間行程中確實發生過) IRQ 工作執行前的 ringbuffer 並導致此 KASAN 報告 (或沒有 KASAN 的當機): 錯誤KASAN在 irq_work_run_list+0x11a/0x13a 中讀取位於 addr 000000006d640a48 的大小為 8 的讀取作業 swapper/0 CPU 0 PID: 0 Comm: swapper Tainted: GWO 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96 /0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>]
    __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>9 /0tickx_1chcchr+00 [<601812b9>]
    __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] 由工作 411 分配save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x9b /0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28
    __kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] 錯誤位址屬於 000000006d640800 的物件該物件屬於大小為 1024 的快取 kmalloc-1k 錯誤位址位於584 位元組在已釋放的 1024 位元組區域內 [000000006d640800, 000000006d640c00) 新增適當的 irq_work_sync()讓工作在緩衝區遭到損毀前完成。在下方修正標籤中提交之前只有一個全域 IRQ 工作因此不存在此問題。 (CVE-2023-53587)

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

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

  - net/mlx5e鎖定後檢查 NOT_READY 旗標狀態。目前會在取得必要鎖定之前執行 NOT_READY 旗標檢查。這會在工作佇列工作同時從 unready_flows 清單中移除流程時引發爭用情形的可能性進而造成從清單中雙重移除並損毀 [0]。移動受 uplink_priv->unready_flows_lock mutex 保護的區段內的旗標檢查以修正此問題。 [0][44376.389654] 一般保護錯誤可能是針對非正式位址 0xdead000000000108 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc 未受污染的 6.4.0-rc4+ #1 [44376.392984] 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP
    0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.396857] 代碼00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 8388 1 48 0b 0 8 01 00 00 4c 89 ef e8 8b 79 8398 0 8b 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP0018:ffff88812cc97570 EFLAGS
    00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS0000 ES0000 CR00000000080050033 [44376.404343] CR20000000000489108 CR3
    0000000123a79003 CR40000000000370ea0 [44376.405004] DR00000000000000000 DR10000000000000000 DR2
    0000000000000000 [44376.405665] DR30000000000000000 DR600000000fffe0ff0 DR70000000000000400 [44376.406339] 呼叫追踪 [44376.406651] [] <TASK> [44376.406939] die_addr+0x33/0x90 [44376.407311] ? exc_general_protection+0x192/0x390 [44376.407795] ? asm_exc_general_protection+0x22/0x30 [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core] [44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core] [44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core] [44376.410529] mlx5e_delete_flower+ 0x24b/0x350 [mlx5_core] [44376.411043] tc_setup_cb_reoffload+0x22/0x80 [44376.411462] fl_reoffload+0x261/0x2f0 [cls_flow] [44376.411907] mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.412481] mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.413044] tcf_block_playback_offloads+0x76/0x170 [44376.413497] tcf_block_unbind+0x7b/0xd0 [44376.413881] tcf_block_setup+0x17d/0x1c0 [44376.414269] ] tcf_block_setup+0x17d/0x1c0 [ [] ] tcf_block_playback_off_/0x.3disra0.044376.414725[[+ 0f_off_1]  ] tcf_block_offload_unbind+0x43/0x70 [44376.415153]
    __tcf_block_put+0x82/0x150 [44376.415532] ingress_destroy+0x22/0x30 [sch_ingress] [44376.415986] qdisc_destroy+0x3b/0xd0 [44376.416343] qdisc_graft+0x4d0/0x620 [44376.416706] tc_get_qdisc+0x1c9/0x3b0 [44376.417074] rtnetlink_vrc_vrc_ms_ 0x29c/0x390 [44376.419978] ? rep_movs_alternative+0x3a/0xa0 [44376.420399] ? rtnl_calcit.isra.0+0x120/0x120 [44376.420813] netlink_rcv_skb+0x54/0x100 [44376.421192] netlink_unicast+0x1f6/0x2c0 [44376.421573] netlink_sendmsg+0x232/0x4a0 [44376.421980] sock_sendmsg+0x38/0x60 [44376.422328]__sys_sendmsg60 +0x1d0/0x1e0 [44376.422709] ? copy_msghdr_from_user+0x6d/0xa0 [44376.423127] ___sys_sendmsg+0x80/0xc0 [44376.423495] ?
    ___sys_recvmsg+0x8b/0xc0 [44376.423869] __sys_sendmsg+0x51/0x90 [44376.424226] do_syscall_64+0x3d/0x90 [44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [44376.425046] RIP 0033:0x7f045134f887 f [44376.425403]000000000000 f d8 64 89 02 48 c7 c0 ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated--- (CVE-2023-53581)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: nft_set_rbtree: fix null deref on element insertion There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem(): general protection fault, probably for non-canonical address 0xdffffc0000000003:
    0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30 Furthermore, there is a possible use-after-free while iterating, 'node' can be free'd so we need to cache the next value to use.
    (CVE-2023-53566)

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

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

  - null_blk一律從 configfs 檢查佇列模式設定。確保檢查 null_validate_conf() 中的裝置佇列模式並傳回 NULL_Q_RQ 的錯誤因為我們不允許舊版 I/O 路徑若無此修補程式我們會在設定佇列模式時發生 OOP從 configfs 到 1 repro 步驟如下 modprobe null_blk nr_devices=0 mkdir config/nullb/nullb0 echo 1 > config/nullb/nullb0/memory_backed echo 4096 > config/nullb/nullb0/blocksize echo 20480 > config/nullb/nullb0 /size echo 1 > config/nullb/nullb0/queue_mode echo 1 > config/nullb/nullb0/power 進入處理器 42 上的 kdb (current=0xffff88810acdd080pid 2372) Oops: (null) 因為 oops @ 0xffffffffc041c329 CPU
    42 PID2372 Commsh 污染的 GON 6.3.0-rc5lblk+ #5 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 RIP
    0010:null_add_dev.part.0+0xd9/0x720 [null_blk] 程式碼01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 85 f7 03 00 00 80 bb 62 01 00 00 008b 48 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20 RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246 RAX: 00010X:000000010X:000
    ffff88811084d800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00 RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000 R10: 0000000000000001 R11:
     R120000000000000000  : 0000000000000002 R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740 FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0 DR0
    ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe +0x72/0xdc RIP0033:0x7fd4460c57a7 程式碼0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 0 75 01 0 800 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7 RDX:
    0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001 RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0 R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002 R13:
    00007fd446198520 R140000000000000002 R1500007fd446198700 </TASK> (CVE-2023-53576)

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

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

  - 已解決 Linux 核心中的下列弱點：sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctp_sched_prio_free_sid+0xab/0x100 [sctp] sctp_stream_free_ext+0x64/0xa0 [sctp] sctp_stream_free+0x31/0x50 [sctp] sctp_association_free+0xa5/0x200 [sctp] Note that it doesn't need to use refcount_t type for this counter, as its accessing is always protected under the sock lock. v1->v2: - add a check in sctp_sched_prio_set to avoid the possible prio_head refcnt overflow. (CVE-2023-53590)

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

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

  - 已解決 Linux 核心中的下列弱點：s390/zcrypt: don't leak memory if dev_set_name() fails When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources.
    Do it. (CVE-2023-53568)

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

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

  - 已解決 Linux 核心中的下列弱點：blk-crypto: make blk_crypto_evict_key() more robust If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments. (CVE-2023-53536)

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

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

  - 已解決 Linux 核心中的下列弱點：iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. (CVE-2022-50505)

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

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

  - 已解決 Linux 核心中的下列弱點：cpufreq: Init completion before kobject_init_and_add() In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP:
    0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50473)

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

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

  - dm完整性呼叫 dm_integrity_init() 錯誤路徑中的 kmem_cache_destroy()否則如果 dm_register_target() 失敗 journal_io_cache 將會洩漏。 (CVE-2023-53604)

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: brcmfmac: Check for probe() id argument being NULL The probe() id argument may be NULL in 2 scenarios: 1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe the device. 2. If a user tries to manually bind the driver from sysfs then the sdio / pcie / usb probe() function gets called with NULL as id argument. 1. Is being hit by users causing the following oops on resume and causing wifi to stop working: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020 Workgueue: events_unbound async_run_entry_fn RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac] <snip> Call Trace: <TASK> brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887] ? pci_pm_resume+0x5b/0xf0 ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x47/0x150 device_resume+0xa2/0x1f0 async_resume+0x1d/0x30 <snip> Fix this by checking for id being NULL. In the PCI and USB cases try a manual lookup of the id so that manually binding the driver through sysfs and more importantly brcmf_pcie_probe() on resume will work. For the SDIO case there is no helper to do a manual sdio_device_id lookup, so just directly error out on a NULL id there.
    (CVE-2023-53565)

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

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

  - 已解決 Linux 核心中的下列弱點：HID: hyperv: avoid struct memcpy overrun warning A previous patch addressed the fortified memcpy warning for most builds, but I still see this one with gcc-9: In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8: In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
    include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My guess is that the WARN_ON() itself is what confuses gcc, so it no longer sees that there is a correct range check. Rework the code in a way that helps readability and avoids the warning. (CVE-2023-53553)

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

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

  - netusbnet修正 usbnet_start_xmit/usb_submit_urb 中的警告。syzbot fuzzer 在 usbnet 驅動程式中發現一個問題usb 1-1: BOGUS urb xfer管道 3 != 類型 1 警告 CPU: 0 PID: 754 at drivers/usb/ core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 連結的模組 CPU
    0 PID754 Commkworker/0:2 未受污染 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 05/27/2023 工作佇列mld mld_ifc_work RIP
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 程式碼7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc9000463f568 EFLAGS00010086 RAX
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001 RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000 R10:
     R110000000000000000  : 0000000000000001 R12: 0000000000000003 R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556a99c15a18 CR30000000028c71000 CR40000000000350ef0 呼叫追踪 <TASK> usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [行列linux/netxmit]netdev_start_xmit 4932 [內嵌] xmit_one net/core/dev.c:3578 [內嵌] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594 ... 造成此錯誤的原因是 usbnet 信任其探查常式在 driver_info 結構中收到的大量端點位址但並未檢查這些端點是否確實存在以及是否有預期的類型和方向。修正只需新增此類檢查即可。 (CVE-2023-53548)

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

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

  - 已解決 Linux 核心中的下列弱點：clk: imx: scu: use _safe list iterator to avoid a use after free This loop is freeing clk so it needs to use list_for_each_entry_safe().
    Otherwise it dereferences a freed variable to get the next item on the loop. (CVE-2023-53572)

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

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

  - nfsd清理 COPY 程式碼路徑中潛在的 nfsd_file refcount 洩漏。nfsd4_copy 結構有兩種不同的類別。其中一個內嵌在復合中且可直接在同步複本中使用。另一個則是在用戶端結構中動態配置、refcount 和追踪。針對內嵌檔案清理作業只會涉及釋出代表其保留的任何 nfsd_files。針對 async 清理作業會稍微複雜一些因此我們需要將其從清單中移除佇列、取消雜湊等。此程式碼中現在至少有一個潛在的 refcount 洩漏。如果 kthread_create 呼叫失敗則原始 nfsd4_copy 物件中的 src 和 dst nfsd_files 都會洩漏。此程式碼路徑中的清理也有些奇怪。在非同步複製的情況下我們將擁有最多四個 nfsd_file 參照 (兩種類型複制結構的 src 和 dst)。
    這些檔案會放在 nfsd4_do_async_copy 的結尾處即使代表內嵌檔案保留的檔案比該結構還長也是如此。進行變更以便我們一律在 nfsd4_copy 傳回前清理內嵌複製結構所持有的 nfsd_file 參照。重新執行 cleanup_async_copy 以處理內部和內部副本。
    移除 nfsd4_cleanup_intra_ssc因為它現在變成非 op。 (CVE-2023-53606)

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

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

  - drm/mipi-dsi移除主機時分離裝置 每當取消註冊 MIPI-DSI 主機時mipi_dsi_host_unregister() 的程式碼就會在該匯流排上目前找到的每個裝置上進行迴圈並將其取消註冊。
    但是它不會先將其從匯流排卸離如果裝置卸離時主機想要執行某些清理則會導致所有類型的資源洩漏。 (CVE-2022-50489)

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

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

  - ALSAymfpci修正探查函式中的 BUG_ONsnd_dma_buffer.bytes 欄位現在會包含對齊的大小而 snd_BUG_ON() 並未將其納入考量進而導致下列結果[ 9.625915] ---------- --[ 在此處切入 ]------------ [ 9.633440] 警告sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci] 的 CPU: 0 PID: 126 9.648926[  ] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_cor e xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy [ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 未受污染的 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da [ 9.722200] 硬體名稱由 OEM 填入
    由 OEM/990FX Extreme4 BIOS P2.70 填入 06/05/2014 [ 9.732204] 工作佇列事件 work_for_cpu_fn [ 9.736580] RIP 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci] [ 9.742594] 程式碼8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41d b fb ff ff ff eb db 41 bd f4 ff ff ff eb [ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287 [ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8 [ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020 [ 9.780876] RBPffff8fa300b5d0d0 R08
    ffff8fa3073a8e50 R0900000000df06bf00 [ 9.788018] R10ffff8fa2df06bf00 R1100000000df068200 R12
    ffff8fa3073a8918 [ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200 [ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000 [ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 [ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4
    00000000000406f0 [ 9.823301] 呼叫追踪 [ 9.825747] <TASK> [ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615] [ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0 [9.841918] local_pci_probe+0x45/0x80 [ 9.845680] work_for_cpu_fn+0x1a/0x30 [ 9.849431] process_one_work+0x1c7/0x380 [ 9.853464] worker_thread+0x1af/0x390 [ 9.857225] ? rescuer_thread+0x3b0/0x3b0 [ 9.861254] kthread+0xde/0x110 [ 9.864414] ? kthread_complete_and_exit+0x20/0x20 [ 9.869210] ret_from_fork+0x22/0x30 [ 9.872792] </TASK> [ 9.874985]
    ---[ end trace 0000000000000000 ]--- (CVE-2023-53607)

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

ID	名稱	嚴重性
269397	Linux Distros 未修補的弱點：CVE-2022-50482	high
269396	Linux Distros 未修補的弱點：CVE-2023-53614	medium
269395	Linux Distros 未修補的弱點：CVE-2023-53589	medium
269394	Linux Distros 未修補的弱點：CVE-2022-50490	high
269393	Linux Distros 未修補的弱點：CVE-2023-53593	medium
269392	Linux Distros 未修補的弱點：CVE-2023-53567	medium
269391	Linux Distros 未修補的弱點：CVE-2022-50476	high
269390	Linux Distros 未修補的弱點：CVE-2023-53615	medium
269389	Linux Distros 未修補的弱點：CVE-2023-53580	medium
269388	Linux Distros 未修補的弱點：CVE-2025-39939	high
269387	Linux Distros 未修補的弱點：CVE-2023-53600	medium
269386	Linux Distros 未修補的弱點：CVE-2023-53595	medium
269385	Linux Distros 未修補的弱點：CVE-2023-53559	high
269384	Linux Distros 未修補的弱點：CVE-2023-53613	high
269383	Linux Distros 未修補的弱點：CVE-2023-53601	medium
269382	Linux Distros 未修補的弱點：CVE-2022-50486	high
269381	Linux Distros 未修補的弱點：CVE-2022-50504	medium
269380	Linux Distros 未修補的弱點：CVE-2022-50496	medium
269379	Linux Distros 未修補的弱點：CVE-2023-53571	medium
269378	Linux Distros 未修補的弱點：CVE-2023-53612	high
269377	Linux Distros 未修補的弱點：CVE-2023-53598	medium
269376	Linux Distros 未修補的弱點：CVE-2023-53549	high
269375	Linux Distros 未修補的弱點：CVE-2022-50477	medium
269373	Linux Distros 未修補的弱點：CVE-2023-53586	high
269372	Linux Distros 未修補的弱點：CVE-2023-53585	high
269371	Linux Distros 未修補的弱點：CVE-2023-53552	high
269370	Linux Distros 未修補的弱點：CVE-2022-50497	high
269369	Linux Distros 未修補的弱點：CVE-2022-50475	medium
269368	Linux Distros 未修補的弱點：CVE-2023-53543	medium
269367	Linux Distros 未修補的弱點：CVE-2022-50484	medium
269366	Linux Distros 未修補的弱點：CVE-2023-53561	medium
269364	Linux Distros 未修補的弱點：CVE-2023-53557	medium
269363	Linux Distros 未修補的弱點：CVE-2023-53535	medium
269362	Linux Distros 未修補的弱點：CVE-2023-53587	high
269361	Linux Distros 未修補的弱點：CVE-2023-53581	high
269360	Linux Distros 未修補的弱點：CVE-2023-53566	medium
269359	Linux Distros 未修補的弱點：CVE-2023-53576	medium
269358	Linux Distros 未修補的弱點：CVE-2023-53590	medium
269357	Linux Distros 未修補的弱點：CVE-2023-53568	high
269356	Linux Distros 未修補的弱點：CVE-2023-53536	high
269355	Linux Distros 未修補的弱點：CVE-2022-50505	high
269354	Linux Distros 未修補的弱點：CVE-2022-50473	medium
269353	Linux Distros 未修補的弱點：CVE-2023-53604	medium
269352	Linux Distros 未修補的弱點：CVE-2023-53565	medium
269351	Linux Distros 未修補的弱點：CVE-2023-53553	high
269350	Linux Distros 未修補的弱點：CVE-2023-53548	high
269349	Linux Distros 未修補的弱點：CVE-2023-53572	high
269348	Linux Distros 未修補的弱點：CVE-2023-53606	high
269347	Linux Distros 未修補的弱點：CVE-2022-50489	high
269346	Linux Distros 未修補的弱點：CVE-2023-53607	high

偵測

Nessus 的 Misc. 系列

high

medium

medium

high

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

high

medium

high

high

high

high

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

high

high

high

medium

medium

medium

high

high

high

high

high

high