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

  - bpf修正 __check_func_call 中的記憶體洩漏。kmemleak 報告此問題未參照的物件 0xffff88817139d000 (大小 2048)comm test_progs, pid 33246, jiffies 4307381979 (age 45851.820s) hex 轉儲存 (前 32 個位元組)01 00 00 00 00 00000 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... ...... backtrace[<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+ 0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b [<0000000000506b7f>/ ] ] entry_SYSCALL_64_after_hwframe+0x63/0xcd 此處的 root 案例為：在函式 prepare_func_exit() 中在 state->curframe--; 之後的異常狀況中未釋放被呼叫者。修正請移動 state->curframe--移到函式的最底部當我們釋放被呼叫者並將 frame[] 指標重設為 NULL 時依照 Andrii 的建議。此外功能
    __check_func_call() 有類似的問題。在 state->curframe++; 之前的異常狀況中被呼叫者也應由 free_func_state() 釋放。 (CVE-2022-49837)

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

偵測

Linux Distros 未修補的弱點：CVE-2022-49837

medium Nessus Plugin ID 249440

找不到變更記錄