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

  - 已解決 Linux 核心中的下列弱點：eth: bnxt: fix out-of-range access of vnic_info array The bnxt_queue_{start | stop}() access vnic_info as much as allocated, which indicates bp->nr_vnics. So, it should not reach bp->vnic_info[bp->nr_vnics]. (CVE-2025-22112)

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

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

  - 某些 WASM 來源檔案可能會在 devtools 中載入時造成當機。此弱點會影響 Firefox < 122。(CVE-2024-0754)

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

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

  - idpf修正 idpf_rx_rsc() 中設定的總和檢查碼。idpf_rx_rsc() 在傳輸標頭尚未設定時會使用 skb_transport_offset(skb)。這會針對 CONFIG_DEBUG_NET=y 版本觸發下列警告。
    DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)) [ 69.261620] 警告./include/linux/skbuff.h:3020 的 CPU: 7 PID: 0 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261629] 模組連結於vfat Fat 虛擬橋接器 intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth [ 69.261644] CPU7 UID 0 PID 0 Commswapper/7 Taintmp-DSW Commswapper/7 Taintmp-GSW #1697 [ 69.261648] 受污染[S]=CPU_OUT_OF_SPEC、[W]=WARN [ 69.261650] RIP 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748) [69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261687] ? report_bug (lib/bug.c:?) [ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285) [ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309) [ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf [69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf [ 69.261712]
    __napi_poll (net/core/dev.c:7194) [ 69.261716] net_rx_action (net/core/dev.c:7265) [ 69.261718] ?
    __qdisc_run (net/sched/sch_generic.c:293) [ 69.261721] sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288) [ 69.261726] handle_softirqs (kernel/softirq.c:561) (CVE-2025-21890)

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

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

  - acpi: nfit修正 acpi_nfit_ctl 中的限制轉換。Syzkaller 已報告 to_nfit_bus_uuid() 中出現一個警告僅可轉譯次要匯流排系列。如果引數等於 NVDIMM_BUS_FAMILY_NFIT == 0就會發出此警告。函式 acpi_nfit_ctl() 首先會驗證 u64 類型的使用者提供的值 call_pkg->nd_family 是否不等於 0。然後該值會轉換為 int且僅之後會與 NVDIMM_BUS_FAMILY_MAX 進行比較。如果 call_pkg->nd_family 為非零而低 32 位元為零則這可導致將無效的引數傳遞至 acpi_nfit_ctl()。此外最好在看到無效使用者輸入時立即傳回 EINVAL。警告不足以防止因其他無效使用者輸入而進一步發生未定義的行為。輸入值的所有檢查都應套用至原始變數 call_pkg->nd_family。 [iweiny更新提交訊息] (CVE-2025-22044)

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

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

  - 已解決 Linux 核心中的下列弱點：net: fec: Use page_pool_put_full_page when freeing rx buffers The page_pool_release_page was used when freeing rx buffers, and this function just unmaps the page (if mapped) and does not recycle the page. So after hundreds of down/up the eth0, the system will out of memory. For more details, please refer to the following reproduce steps and bug logs.
    To solve this issue and refer to the doc of page pool, the page_pool_put_full_page should be used to replace page_pool_release_page. Because this API will try to recycle the page if the page refcnt equal to 1. After testing 20000 times, the issue can not be reproduced anymore (about testing 391 times the issue will occur on i.MX8MN-EVK before). Reproduce steps: Create the test script and run the script. The script content is as follows: LOOPS=20000 i=1 while [ $i -le $LOOPS ] do echo TINFO:ENET $curface up and down test $i times org_macaddr=$(cat /sys/class/net/eth0/address) ifconfig eth0 down ifconfig eth0 hw ether $org_macaddr up i=$(expr $i + 1) done sleep 5 if cat /sys/class/net/eth0/operstate | grep 'up';then echo TEST PASS else echo TEST FAIL fi Bug detail logs: TINFO:ENET up and down test 391 times [ 850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0:
    link becomes ready [ 853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec [ 931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec TINFO:ENET up and down test 392 times [ 991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec [ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec [ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec [1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1096.839092] IPv6:
    ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec [ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec [ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec [ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec TINFO:ENET up and down test 393 times [ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec [ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec [ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec [ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec [ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec [ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec [ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec [ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec [ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec [ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec [ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec TINFO:ENET up and down test 394 times [ 1492.8305 ---truncated--- (CVE-2023-52998)

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

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

  - usbnet修正中斷連線時的 linkwatch 釋放後使用問題 usbnet 使用 usbnet_deferred_kevent() 工作執行可能會休眠的工作。中斷連線時最初在 中等候工作完成
    ->ndo_stop()。但在 2003 年這已由歷程記錄提交移至 ->disconnect() [修補程式] USBusbnet防止異常 rtnl 鎖死 https://git.kernel.org/tglx/history/c/0f138bbfd83c 進行此變更是因為當時核心的工作佇列實作不允許等待單一工作。必須呼叫 flush_scheduled_work() 來等待 *所有* 工作完成而這可在等待 ->ndo_stop() 中保留 rtnl_mutex 的 usbnet_deferred_kevent() 時鎖死。此認可可解決一個問題但也產生另一個問題 它會在 USB 乙太網路驅動程式 aqc111.c、asix_devices.c、ax88179_178a.c、ch9200.c 和 smsc75xx.c 中造成釋放後使用* 如果驅動程式收到連結變更中斷在中斷連線之前它們會在 (non-sleepable) ->status() 回呼中提出 EVENT_LINK_RESET 並排程 usbnet_deferred_kevent()。 * usbnet_deferred_kevent() 叫用驅動程式的 ->link_reset() 回呼該回呼會呼叫 netif_carrier_{on,off}()。 * 其會排程工作 linkwatch_event()。由於在 unregister_netdev() 之後等候 usbnet_deferred_kevent()因此 netif_carrier_{on,off}() 可在未註冊的 netdev 上執行且 linkwatch_event() 可在 free_netdev() 之後執行進而造成釋放後使用。2010 年 usbnet 變更為只等待 usbnet_deferred_kevent() 的單一執行個體而非等待認可 23f333a2bfaf 的 *所有* 工作 (drivers/net不使用 flush_scheduled_work())。遺憾的是認可忽略將等待移回 ->ndo_stop()。好不容易才更正這個疏漏。 (CVE-2022-50220)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件: Server: Optimizer)。受到影響的支援版本是 8.0.21 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2021-2412)

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

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

  - 0.12.4 之前的 yhirose/cpp-httplib 套件版本在使用未受信任的使用者輸入設定 HTTP .Patch、.Post、.Put 和 .Delete 要求中的 content-type 標頭時容易發生 CRLF 插入。
    這可導致邏輯錯誤和其他不當行為。 **注意** 此問題之所以存在是因為 [CVE-2020-11709](https://security.snyk.io/vuln/SNYK-UNMANAGED-YHIROSECPPHTTPLIB-2366507) 的修正不完整。 (CVE-2023-26130)

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

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

  - Oracle MySQL 的 MySQL 伺服器產品中存有弱點 (元件: Server: Optimizer)。受到影響的支援版本是 8.0.23 和之前的版本。攻擊此弱點的難度較小，經由多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2021-2212)

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

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

  - ext4修正 1k 區塊檔案系統上的另一個差一 fsmap 錯誤顯然 syzbot 發現會發出此 FSMAP 呼叫struct fsmap_head cmd = { .fmh_count = ...; .fmh_keys = { { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, }, ... } ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);如果基礎檔案系統是 1k 區塊 ext4 檔案系統則會產生此當機問題fs/ext4/ext4.h:3331! 的核心錯誤無效的 opcode0000 [#1] PREEMPT SMP CPU3 PID3227965 Commxfs_io 污染GWO 6.2.0-rc8-achx 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.15.0-1 2014 年 4 月 1 日 RIP 0010 :ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS
    00010246 RAXffff888004978000 RBXffffc90007c03a20 RCXffff888041618000 RDX0000000000000000 RSI
    00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000ffffffff R14:
     R150000000000000c40  : ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3:
    000000007f80f001 CR4: 00000000001706e0 Call Trace: <TASK> ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 do_syscall_64+0x2b/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP0033:0x7fdf20558aff RSP0132b:030 EFLAe9:030007fdf
    00000246 ORIG_RAX 0000000000000010 RAX ffffffffffffffda RBX 00000000000200c0 RCX 00007fdf20558aff RDX
    00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13:
    00005625be70d994 R140000000000000800 R150000000000000000 對於 GETFSMAP 呼叫呼叫端會將其區塊編號寫入 fsmap_head.fmh_keys[01].fmr_device 以選取實體區塊裝置。若要查詢裝置子範圍的對應範圍的起始位元組會寫入 fsmap_head.fmh_keys[0].fmr_physical而范圍的最後一個位元組會寫入 fsmap_head.fmh_keys[1].fmr_physical。IOW 若要查詢哪些對應與 /dev/sda 的位元組 3-14 重疊您應將輸入設定如下fmh_keys[0] = { .fmr_device = Major(8, 0), .fmr_physical = 3}, fmh_keys [1] = { .fmr_device = Major(8, 0), .fmr_physical = 14}其會傳回從實體位移 3 開始的 12 位元組中對應的任何項目。損毀是因為金鑰的範圍驗證不足所致 [1 ] 在 ext4_getfsmap_datadev 中。在 1k 區塊檔案系統上區塊 0 不屬於檔案系統這表示 s_first_data_block 為非零。 ext4_get_group_no_and_offset 會先從 blocknr 引數減去此數量再將其破解為群組編號和群組內的區塊編號。IOW封鎖群組 0 跨越區塊 1-8192 (以 1 為基礎)而不是像較大區塊大小所發生的情況一樣跨越 0-8191 (以 0)。此編碼的最終結果是 blocknr < s_first_data_block 不是此函式的有效輸入。end_fsb 變數是從從使用者空間複製的金鑰設定這表示在以上範例中其值為零。這會導致反向溢位blocknr = blocknr - le32_to_cpu(es->s_first_data_block);然後在 -1 除法運算 offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits;將群組編號 (2^32-1) 留在 blocknr 中大到無法使用。 ext4_getfsmap_check_keys 已檢查 keys[0 ---truncated--- (CVE-2023-53143)

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

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

  - net_sched防止建立具有 TC_H_ROOT 的類別。在向上遍歷 qdisc 樹狀結構以更新父項積存計數器時qdisc_tree_reduce_backlog() 函式會使用 TC_H_ROOT 作為終止條件。
    但是如果使用 classid TC_H_ROOT 建立類別遊走會提前在此類別終止而不會到達實際的 root qdisc造成父項統計資料遭到錯誤維護。據 Mingi Cho 報告在 DRR 的情況下這可導致當機。依照 Jamal 的建議，防止在所有 qdisc 類型中建立 classid TC_H_ROOT (0xFFFFFFFF) 的任何 Qdisc 類別。 (CVE-2025-21971)

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

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

  - 在 4.14.6 之前的 Linux 核心中，net/ipv4/raw.c 的 raw_sendmsg() 函式在 inet-> hdrincl 中存在爭用情形，其會導致系統不針對堆疊指標的使用進行初始化；而本機使用者可藉此執行程式碼並取得權限。(CVE-2017-17712)

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

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

  - 在 Valkey 之前的 8.1.1 中networking.c 的 setDeferredReply對於 prev->size - prev->used 有整數反向溢位。 (CVE-2025-49112)

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

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

  - ALSAusb-audio移除時正確終止計時器。USB 音訊 MIDI 程式碼會初始化計時器但在極少數情況下驅動程式可能會在沒有中斷連線呼叫的情況下釋放。這會讓計時器在透過 snd_usbmidi_free() 釋放指派的物件時保持在作用中狀態而 fuzzer 發現這會在啟用除錯組態時出現核心警告。為避免此問題請將 timer_shutdown_sync() 放在 snd_usbmidi_free() 上以便可以正確終止計時器。執行期間也將中斷連線回呼中的現有 timer_delete_sync() 取代為 timer_shutdown_sync()。 (CVE-2025-38105)

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

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

  - 已解決 Linux 核心中的下列弱點：iio: Fix the sorting functionality in iio_gts_build_avail_time_table The sorting in iio_gts_build_avail_time_table is not working as intended.
    It could result in an out-of-bounds access when the time is zero. Here are more details: 1. When the gts->itime_table[i].time_us is zero, e.g., the time sequence is `3, 0, 1`, the inner for-loop will not terminate and do out-of-bound writes. This is because once `times[j] > new`, the value `new` will be added in the current position and the `times[j]` will be moved to `j+1` position, which makes the if-condition always hold. Meanwhile, idx will be added one, making the loop keep running without termination and out-of-bound write. 2. If none of the gts->itime_table[i].time_us is zero, the elements will just be copied without being sorted as described in the comment Sort times from all tables to one and remove duplicates. For more details, please refer to https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com. (CVE-2024-43825)

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

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

  - 在 Linux 核心 5.11.3 及之前所有版本中發現一個問題。drivers/scsi/scsi_transport_iscsi.c 受到無權限使用者能夠製作 Netlink 訊息的負面影響。(CVE-2021-27364)

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

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

  - 已解決 Linux 核心中的下列弱點：apparmor: Fix memleak in aa_simple_write_to_buffer() When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue. (CVE-2022-50074)

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

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

  - 已解決 Linux 核心中的下列弱點：bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc... The work is then not part of a memory reclaim path... Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? __queue_work+0x14a/0x3e0 [ 40.969753] flush_work+0x10/0x20 [40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [40.969761] unregister_netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] device_release_driver_internal+0xf0/0x1d0 [ 40.969778] device_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.969786] device_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi] [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] device_for_each_child+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi] (CVE-2021-46970)

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

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

  - dbAdjTree Syzkaller 中的 FS:JFS:UBSANarray-index-out-of-boundsarray-index-out-of-bounds 報告了下列問題signed char[1365]') CPU1 PID109 CommjfsCommit 未受污染的 6.6.0-rc3-syzkaller #0 硬體名稱
    Google Google Compute Engine/Google Compute Engine、BIOS Google 08/04/2023 呼叫追踪 <TASK> __dump_stack lib/dump_stack.c:88 [內嵌] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c 217 [內嵌] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+04eb/00dmap fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [內嵌] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [內嵌] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x88/0x88/arch /x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ====================== ================================================== ======== 核心錯誤 - 未同步UBSANpanic_on_warn set ... CPU：1 PID：109 命令：jfsCommit 未污染 6.6.0-rc3-syzkaller #0 硬體名稱：Google Google Compute Engine/Google Compute Engine，BIOS Google 2023 年 8 月 4 日 呼叫追蹤：
    <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> 核心位移：已停用 86400 秒後重啟… 若 lp 的值大於 CLTREEESIZE (即 stree 的最大大小)，則會導致此問題。新增一項簡單的檢查即可解決此問題。Dave：由於函式會傳回 void，因此若要妥善處理錯誤，可能需要更激進的程式碼重組。由於缺少明確的選項，所以我修改了目前所用的 Osama 修補程式 WARN_ON_ONCE。修補程式已經過 syzbot 測試。(CVE-2023-52604)

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

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

  - 如果在收到權限提示 (例如地理位置權限提示) 的同時於正確位置顯示表單有效性訊息，則有效性訊息已經隱藏提示，進而可能導致使用者遭誘騙而授予權限。此弱點會影響 Firefox 94 更早版本、Thunderbird 91.3 更早版本和 Firefox ESR 91.3 更早版本。(CVE-2021-38508)

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

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

  - riscvmodule修正超出邊界的重新定位存取。目前的程式碼允許 rel[j] 存取重新定位區段結尾之後的一個元素。簡化為 num_relocations其等同於現有的大小運算式。 (CVE-2025-37975)

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

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

  - 在 Linux 核心的記憶體管理子系統的 mm/mempolicy.c 中發現一個釋放後使用瑕疵。
    此問題是由 mbind() 和 VMA 鎖定頁面之間的爭用錯誤所造成且可能允許本機攻擊者造成系統當機或導致核心資訊洩漏。 (CVE-2023-4611)

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

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

  - 已解決 Linux 核心中的下列弱點：io_uring: fix memleak in io_init_wq_offload() I got memory leak report when doing fuzz test: BUG: memory leak unreferenced object 0xffff888107310a80 (size 96): comm syz-executor.6, pid 4610, jiffies 4295140240 (age 20.135s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [inline] [<000000001974933b>] kzalloc include/linux/slab.h:721 [inline] [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline] [<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955 [<0000000039d0800d>]
    __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016 [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline] [<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline] [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline] [<000000008482e78c>]
    __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301 [<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae CPU0 CPU1 io_uring_enter io_uring_enter io_uring_add_tctx_node io_uring_add_tctx_node __io_uring_add_tctx_node
    __io_uring_add_tctx_node io_uring_alloc_task_context io_uring_alloc_task_context io_init_wq_offload io_init_wq_offload hash = kzalloc hash = kzalloc ctx->hash_map = hash ctx->hash_map = hash <- one of the hash is leaked When calling io_uring_enter() in parallel, the 'hash_map' will be leaked, add uring_lock to protect 'hash_map'. (CVE-2021-47292)

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

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

  - 已解決 Linux 核心中的下列弱點：Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot Commit 272970be3dab (Bluetooth: hci_qca: Fix driver shutdown on closed serdev) will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f (Bluetooth: btusb: Fix triggering coredump implementation for QCA) of bluetooth-next tree.
    commit b23d98d46d28 (Bluetooth: btusb: Fix triggering coredump implementation for QCA) of linus mainline tree. (CVE-2024-42137)

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

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

  - 序列max3100移除驅動程式時更新 uart_driver_registered。移除最後一個 MAX3100 裝置會觸發驅動程式移除。但是程式碼不會更新個別的全域變數且在 insmod rmmod insmod 循環之後核心 oopses: max3100 spi-PRP0001:01max3100_probe新增連接埠 0 錯誤
    核心 NULL 指標解除參照位址0000000000000408 ... RIP
    0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 更新實際狀態以便下次再次註冊 UART 驅動程式。Hugo 也發現探查中的錯誤路徑也會受到設定及不清除變數的影響。在成功的 uart_register_driver() 呼叫之後移動指派而非將其清除。 (CVE-2024-38633)

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

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

  - 根據 W3C 內容安全性原則草稿規定，建立違規報告時，使用者代理程式必須確認來源檔案是頁面要求的 URL，即預先重新導向。如果這不可能，使用者代理程式必須將 URL 剝離至源，以避免意外洩漏。在特定重新導向類型下，Firefox 會將來源檔案錯誤地設定為重新導向的目的地。此問題已修正為重新導向目的地的來源。此弱點會影響 Firefox < 86、Thunderbird < 78.8 和 Firefox ESR < 78.8。(CVE-2021-23969)

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

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

  - virtio-pci修正針對 admin 命令完成傳回的結果大小 virtio_pci_admin_dev_parts_get() 傳回的結果大小比實際結果資料大小大 8 位元組。此問題之所以發生是因為命令的 result_sg_size 欄位是以 virtqueue_get_buf() 的結果長度填入其中包含資料大小及額外 8 位元組的狀態。這個過大的結果大小會造成兩個問題1. 傳輸至目的地的狀態最後包含 8 位元組的額外資料。 2. 核心中配置的緩衝區可能小於傳回的大小導致超出配置大小時讀取失敗。認可透過從 virtqueue_get_buf() 的結果中減去狀態大小來修正此問題。此修正已經透過 virtio-net、virtio-net-transitional 和 virtio-blk 裝置的即時移轉進行測試。 (CVE-2025-38314)

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

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

  - 具有最低權限的 Web 延伸模組可以建立 `StreamFilter`其可用於讀取和修改任何網站上要求的回應內文。此弱點會影響 Firefox < 129、Firefox ESR < 115.14、Firefox ESR < 128.1、Thunderbird < 128.1 和 Thunderbird < 115.14。
    (CVE-2024-7525)

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

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

  - comedivmk80xx修正不完整的端點檢查雖然 vmk80xx 已實作端點檢查但有些項目仍可能被破解。視硬體型號而定URB 可以有大量或中斷類型而目前版本的 vmk80xx_find_usb_endpoints() 函式並未完全考慮到這一點。雖然此警告的危害性似乎不大，但至少會讓設定了「panic_on_warn」的系統當機。修正 Syzkaller [1] 發現的問題方法是稍微簡化 usb_find_common_endpoints() 的端點檢查程序並確保只存在預期的端點類型。此修補程式尚未在真正的硬體上經過測試。 [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 警告: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/ core/urb.c:503 ... 呼叫追踪 <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [內嵌] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c :818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ... Syzkaller 也發現類似問題(CVE-2024-27001)

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

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

  - Oracle MySQL 的 MySQL Server 產品中存有弱點 (元件：Server: DML)。受影響的支援版本是 8.0.0-8.0.42、8.4.0-8.4.5 和 9.0.0-9.3.0。攻擊此弱點的難度較小，經由多個通訊協定存取網路的低權限攻擊者可藉此入侵 MySQL 伺服器。若成功攻擊此弱點，未經授權即可造成 MySQL 伺服器懸置或經常重複性當機 (完全 DOS)。(CVE-2025-50078)

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

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

  - 在 ashmem.c 的 ashmem_ioctl 中存在一個超出邊界寫入這是因為存取 asma 時未充分鎖定所致。這可導致本機權限提升進而允許將程式碼作為有權限的處理程序執行而無需額外的執行權限。不需使用者互動即可惡意利用。產品：
    Android。版本：Android 核心。Android ID A-66954097。 (CVE-2017-13216)

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

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

  - 在 Linux 核心 5.3.9 之前版本中，drivers/iio/imu/adis_buffer.c 中的 adis_update_scan_mode() 函式有一個記憶體洩漏問題，攻擊者可藉此造成拒絕服務 (記憶體消耗)，亦即 CID-ab612b1daf41。
    (CVE-2019-19060)

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

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

  - spispi-mt65xx修正中斷處理常式中的 NULL 指標存取spi_transfer 中的 TX 緩衝區可能是 NULL 指標因此中斷處理常式最終可能會寫入無效的記憶體並造成當機。在 trans->tx_buf 中新增使用前的檢查。 (CVE-2024-27028)

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

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

  - ethernet修正 xemaclite_of_probe 中的錯誤處理。此節點指標由 of_parse_phandle() 傳回且此函式中的 refcount 增加。呼叫 of_node_put() 以避免 refcount 洩漏。如同 remove 函式一樣。 (CVE-2022-48860)

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

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

  - 已解決 Linux 核心中的下列弱點：block: ublk: extending queue_size to fix overflow When validating drafted SPDK ublk target, in a case that assigning large queue depth to multiqueue ublk device, ublk target would run into a weird incorrect state. During rounds of review and debug, An overflow bug was found in ublk driver. In ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH is 4096 which means each ublk queue depth can be set as large as 4096. But when setting qd for a ublk device, sizeof(struct ublk_queue) + depth * sizeof(struct ublk_io) will be larger than 65535 if qd is larger than 2728. Then queue_size is overflowed, and ublk_get_queue() references a wrong pointer position. The wrong content of ublk_queue elements will lead to out-of-bounds memory access. Extend queue_size in ublk_device as unsigned int. (CVE-2023-52980)

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

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

  - Windows 上 Apache HTTP Server 中的伺服器端要求偽造 (SSRF) 可能會透過傳遞未經驗證要求輸入的 mod_rewrite 或 apache 運算式，將 NTLM 雜湊洩漏給惡意伺服器。此問題會影響 Apache HTTP Server 2.4.0 至 2.4.63 (含) 版。注意：Apache HTTP Server Project 將透過 UNC 路徑，針對接受有關 SSRF 的弱點報告設定更高的標準。伺服器針對系統管理員指示伺服器開啟 UNC 路徑提供有限的保護。Windows 伺服器應根據 NTLM 驗證的特性，限制其透過 SMB 連線的主機。
    (CVE-2024-43394)

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

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

  - 在來自 CAF 且使用 Linux 核心的所有 Android 版本中核心驅動程式有一個差一緩衝區過度讀取弱點。 (CVE-2017-8240)

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

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

  - 已解決 Linux 核心中的下列弱點：af_unix: Fix task hung while purging oob_skb in GC. syzbot reported a task hung; at the same time, GC was looping infinitely in list_for_each_entry_safe() for OOB skb. [0] syzbot demonstrated that the list_for_each_entry_safe() was not actually safe in this case. A single skb could have references for multiple sockets. If we free such a skb in the list_for_each_entry_safe(), the current and next sockets could be unlinked in a single iteration. unix_notinflight() uses list_del_init() to unlink the socket, so the prefetched next socket forms a loop itself and list_for_each_entry_safe() never stops. Here, we must use while() and make sure we always fetch the first socket. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID:
    5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline] RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP:
    0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207 Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74 RSP: 0018:ffffc900033efa58 EFLAGS: 00000283 RAX:
    ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189 RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70 RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c R10:
    ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800 R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> unix_gc+0x563/0x13b0 net/unix/garbage.c:319 unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683 unix_release+0x91/0xf0 net/unix/af_unix.c:1064 __sock_release+0xb0/0x270 net/socket.c:659 sock_close+0x1c/0x30 net/socket.c:1421
    __fput+0x270/0xb80 fs/file_table.c:376 task_work_run+0x14f/0x250 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xa8a/0x2ad0 kernel/exit.c:871 do_group_exit+0xd4/0x2a0 kernel/exit.c:1020 __do_sys_exit_group kernel/exit.c:1031 [inline] __se_sys_exit_group kernel/exit.c:1029 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP:
    0033:0x7f9d6cbdac09 Code: Unable to access opcode bytes at 0x7f9d6cbdabdf. RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
    00007f9d6cbdac09 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006 R10: 0000000000000006 R11: 0000000000000246 R12:
    00007f9d6cc552b0 R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70 </TASK> (CVE-2024-26780)

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

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

  - 在 GnuTLS 軟體的 _gnutls_fig_common_ciphersuite() 中發現一個 NULL 指標解除參照瑕疵。
    (CVE-2025-6395)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf, cgroup: Fix kernel BUG in purge_effective_progs Syzkaller reported a triggered kernel BUG as follows: ------------[ cut here]------------ kernel BUG at kernel/bpf/cgroup.c:925! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP:
    0010:__cgroup_bpf_detach+0x1f2/0x2a0 Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 8b 0c5 RSP:
    0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 0000000000000000 R08:
    ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Call Trace: <TASK> cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX:
    000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11:
    0000000000000246 R12: 00007ffeb487dc20 R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Repetition steps: For the following cgroup tree, root | cg1 | cg2 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs attach type is NONE or OVERRIDE. 2. write 1 to /proc/thread-self/fail-nth for failslab. 3. detach prog1 for cg1, and then kernel BUG occur. Failslab injection will cause kmalloc fail and fall back to purge_effective_progs. The problem is that cg2 have attached another prog, so when go through cg2 layer, iteration will add pos to 1, and subsequent operations will be skipped by the following condition, and cg will meet NULL in the end.
    `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` The NULL cg means no link or prog match, this is as expected, and it's not a bug. So here just skip the no match situation. (CVE-2022-49970)

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

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

  - 在 5.1.8 版之前的 Linux 核心中發現一個問題。在 sound/usb/line6/pcm.c 驅動程式中，惡意 USB 裝置可造成 NULL 指標解除參照問題。(CVE-2019-15223)

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

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

  - uprobes拒絕 uprobe_write_opcode() 中的共用 zeropage。我們在 syzkaller 測試中觸發了下列損毀錯誤：處理程序 syz.7.38 pfn:1eff3 頁面refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 中的頁面狀態錯誤flags
    0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.13.0-1ubuntu1.1 2014 年 4 月 1 日 呼叫追踪 <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint..part 0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0
    __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280
    __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 錯誤rss 計數器狀態 mm:00000000452453e0 type:MM_FILEPAGES val:-1 重現測試案例可用於creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0 \x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f00000004000)= {0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={&(0x7f00000ffc00000/00100)={&(0x740000ffc0000000/00xx) }, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3) 、 &(0x7f0000000200)=ANY=[@ANYBLOB=1800000000120000000000000000000095]、 &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', @fa llback=0x30、0xffffffffffffffff、0x0、0x0、0x0、0x0、0x0、0x0、0x0、0x0、0x0、0x0、0x0、0x10、0x0、@void、@value}、0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040) )={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)原因是在沒有增加 mfill_atomic_pte_zeropage() 中的 RSS 計數的情況下對 PTE 設定了零 pfn且零對開本的參照計數不會相應增加。然後在 uprobe_write_opcode()->__replace_page() 中對相同 pfn 執行作業以無條件減少 RSS 計數和 old_folio 的 refcount。因此引入了兩個錯誤 1. RSS 計數不正確當處理程序結束時check_mm() 報告錯誤 Bad rss-count。 2. folio->refcount 為零時會釋放保留的 folio (零 folio)然後 free_pages_prepare->free_page_is_bad() 報告錯誤頁面狀態錯誤。除此之外理論上也可觸發下列警告__replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio) 考慮到在零 folio 上發生 uprobe 是非常罕見的情況僅在拒絕 get_user_page_vma_remote() 之後立即拒絕零舊的作品集。 [ Mingo清理變更記錄 ] (CVE-2025-21881)

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

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

  - 已解決 Linux 核心中的下列弱點：exfat: fix the new buffer was not zeroed before writing Before writing, if a buffer_head marked as new, its data must be zeroed, otherwise uninitialized data in the page cache will be written. So this commit uses folio_zero_new_buffers() to zero the new buffers before ->write_end(). (CVE-2024-57943)

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

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

  - 在 Linux 核心的 Netfilter 子系統中發現緩衝區溢位弱點。此問題可引致洩漏堆疊和堆積位址洩漏，並允許攻擊者透過執行任意程式碼將本機特權提升至 root 使用者權限。(CVE-2023-0179)

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

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

  - ARMOMAP2+顯示修正 refcount 洩漏錯誤。在 omapdss_init_fbdev() 中of_find_node_by_name() 會傳回 refcount 遞增的節點指標。當不再使用 of_node_put() 時應予以使用。
    (CVE-2022-50203)

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

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

  - 在 5.16.3之前的 Linux 核心中drivers/scsi/ufs/ufs-mediatek.c 錯誤解譯 Regulator_get 傳回值 (在錯誤情況下預期其為 NULL但實際上為錯誤指標)。 (CVE-2023-23001)

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

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

  - 已解決 Linux 核心中的下列弱點：amt: fix memory leak for advertisement message When a gateway receives an advertisement message, it extracts relay information and then it should be freed. But the advertisement handler doesn't free it. So, memory leak would occur. (CVE-2022-49461)

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

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

  - 已解決 Linux 核心中的下列弱點：rcu: Fix buffer overflow in print_cpu_stall_info() The rcuc-starvation output from print_cpu_stall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow. Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code. This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2024-38576)

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

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

  - Oracle MySQL 的 MySQL Server 產品中的弱點 (元件ServerTelemetry)。受到影響的支援版本是 8.4.2 與更早版本，以及 9.0.1 與更早版本。攻擊此弱點有一定難度，可以透過多個通訊協定存取網路的高特權攻擊者可藉此入侵 MySQL 伺服器。
    若攻擊成功，攻擊者未經授權即可讀取部分 MySQL Server 可存取資料。(CVE-2024-21244)

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

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

  - Mozilla 開發人員和社群成員 Lukas Bernhard、Gabriele Svelto 、Randell Jesup 及 Mozilla Fuzzing 團隊報告 Firefox 107 中存在記憶體安全錯誤。某些錯誤顯示記憶體會遭到損毀，我們推測若有心人士有意操控，可能惡意利用其中部分錯誤執行任意程式碼。此弱點會影響 Firefox 108 以下的版本。(CVE-2022-46879)

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

ID	名稱	嚴重性
244735	Linux Distros 未修補的弱點：CVE-2025-22112	high
244734	Linux Distros 未修補的弱點：CVE-2024-0754	medium
244733	Linux Distros 未修補的弱點：CVE-2025-21890	medium
244732	Linux Distros 未修補的弱點：CVE-2025-22044	high
244731	Linux Distros 未修補的弱點：CVE-2023-52998	medium
244730	Linux Distros 未修補的弱點：CVE-2022-50220	medium
244729	Linux Distros 未修補的弱點：CVE-2021-2412	medium
244728	Linux Distros 未修補的弱點：CVE-2023-26130	high
244727	Linux Distros 未修補的弱點：CVE-2021-2212	medium
244726	Linux Distros 未修補的弱點：CVE-2023-53143	medium
244725	Linux Distros 未修補的弱點：CVE-2025-21971	medium
244724	Linux Distros 未修補的弱點：CVE-2017-17712	high
244723	Linux Distros 未修補的弱點：CVE-2025-49112	low
244722	Linux Distros 未修補的弱點：CVE-2025-38105	medium
244721	Linux Distros 未修補的弱點：CVE-2024-43825	high
244720	Linux Distros 未修補的弱點：CVE-2021-27364	high
244719	Linux Distros 未修補的弱點：CVE-2022-50074	medium
244718	Linux Distros 未修補的弱點：CVE-2021-46970	medium
244717	Linux Distros 未修補的弱點：CVE-2023-52604	high
244716	Linux Distros 未修補的弱點：CVE-2021-38508	medium
244715	Linux Distros 未修補的弱點：CVE-2025-37975	high
244714	Linux Distros 未修補的弱點：CVE-2023-4611	medium
244713	Linux Distros 未修補的弱點：CVE-2021-47292	medium
244712	Linux Distros 未修補的弱點：CVE-2024-42137	medium
244711	Linux Distros 未修補的弱點：CVE-2024-38633	medium
244710	Linux Distros 未修補的弱點：CVE-2021-23969	medium
244709	Linux Distros 未修補的弱點：CVE-2025-38314	high
244708	Linux Distros 未修補的弱點：CVE-2024-7525	high
244707	Linux Distros 未修補的弱點：CVE-2024-27001	medium
244706	Linux Distros 未修補的弱點：CVE-2025-50078	medium
244705	Linux Distros 未修補的弱點：CVE-2017-13216	high
244704	Linux Distros 未修補的弱點：CVE-2019-19060	high
244703	Linux Distros 未修補的弱點：CVE-2024-27028	medium
244702	Linux Distros 未修補的弱點：CVE-2022-48860	medium
244701	Linux Distros 未修補的弱點：CVE-2023-52980	high
244700	Linux Distros 未修補的弱點：CVE-2024-43394	high
244699	Linux Distros 未修補的弱點：CVE-2017-8240	high
244698	Linux Distros 未修補的弱點：CVE-2024-26780	medium
244697	Linux Distros 未修補的弱點：CVE-2025-6395	medium
244696	Linux Distros 未修補的弱點：CVE-2022-49970	high
244695	Linux Distros 未修補的弱點：CVE-2019-15223	medium
244694	Linux Distros 未修補的弱點：CVE-2025-21881	medium
244693	Linux Distros 未修補的弱點：CVE-2024-57943	high
244692	Linux Distros 未修補的弱點：CVE-2023-0179	high
244691	Linux Distros 未修補的弱點：CVE-2022-50203	high
244690	Linux Distros 未修補的弱點：CVE-2023-23001	medium
244689	Linux Distros 未修補的弱點：CVE-2022-49461	medium
244688	Linux Distros 未修補的弱點：CVE-2024-38576	high
244687	Linux Distros 未修補的弱點：CVE-2024-21244	low
244686	Linux Distros 未修補的弱點：CVE-2022-46879	high

偵測

Nessus 的 Misc. 系列

high

medium

medium

high

medium

medium

medium

high

medium

medium

medium

high

low

medium

high

high

medium

medium

high

medium

high

medium

medium

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

high

high

high

medium

medium

high

medium

medium

high

high

high

medium

medium

high

low

high