Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - btrfsPageError が設定されている場合は WARN_ON() を実行しません。エクステントバッファ操作を行う際は必ず assert_eb_page_uptodate() を呼び出し、更新されていないページで操作を行っている場合は大規模なエラーを報告します。Tenable のオーバーフローテストにより、週の前半にこの警告がキャッチされました。 警告 CPU1 PID553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU1 PID553508 通信 kworker/u4:13 汚染 GW 5.17。 0-rc3+ #564 ハードウェア名: QEMU Standard PC (Q35 + ICH9、2009)、BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017fffffc0002112 RBX: ffff6e74453f9c0 RCX: 0000000000001000 RDX: ffff6e74467c887 RSI:
    ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14:
     R150000000001500000  : 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3:
    0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 これは c2e39305299f01 で部分的に修正されましたbtrfs書き込みに失敗した場合のエクステントバッファの更新をクリアします、しかしこの修正は全て、書き込みに失敗した後にエクステントバッファが見つからなくなります。すでに見つかっているバッファを使用し続けることができませんでした。このケースでは、ブロックグループをキャッシュするためにコミットルートを検索しているため、トランザクションのコミットを開始し、コミットルートを切り替えてから書き込みを開始できます。切り替え後、まだ書き込まれていないエクステントバッファを検索し、そのブロックグループの処理を開始できます。次に、そのブロックの書き込み、ページの Update の消去に失敗し、これらのエラーを漏洩し始めます。
    通常、ここでは特定の程度までツリーロックによって保護されます。ブロックを読み取る場合、そのブロックの読み取りはロックされ、ブロックを書き込みのために送信する前に、ライターがブロックをロックしないようにブロックします。ただし、これは必ずしもフール証明ではありません。これは、submit_bio を実行する前や、エクステントバッファのロックとロック解除を行った後に、読み取りが行われる可能性があるためです。また、この特定のケースでは、path->skip_locking が設定されているため、ここでは保存されません。読み取ったときには有効であったが、使用中には無効になったブロックを単に入手します。特にしたいのは、ブロックを読み取ったものの、それが [Uptodate] とマークされていないケースをキャッチすることです。読み取りで ClearPageError() が実行されるため、!Uptodate で !Error である場合、ページを読み取るために正しい行いをしていないことが分かります。!Uptodate && !Error をチェックすることでこれを修正します。この方法では、使用中にバッファが無効になった場合でも苦情を言いません。また、完全なインキャッシュがあることを確認するチェックのスタイルは維持されます。やりとりしている間はブロックされます。CVE-2022-48902

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - btrfs: do not WARN_ON() if we have PageError set Whenever we do any extent buffer operations we call     assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight     tests caught this warning earlier this week WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849     assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache     btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246     RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI:
    ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000     R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14:
    0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000)     knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3:
    0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70     free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ?     rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ?     rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ?     lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ?     process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ?     kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This was partially fixed by c2e39305299f01     (btrfs: clear extent buffer uptodate when we fail to write it), however all that fix did was keep us     from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer     that we already had found. In this case we're searching the commit root to cache the block group, so we     can start committing the transaction and switch the commit root and then start writing. After the switch     we can look up an extent buffer that hasn't been written yet and start processing that block group. Then     we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors.
    Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block     read locked, and we block the writer from locking the block before we submit it for the write. However     this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we     locked and unlocked the extent buffer. Also in this particular case we have path->skip_locking set, so     that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while     we were using it. What we really want is to catch the case where we've read a block but it's not marked     Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right     thing for reading the page. Fix this by checking !Uptodate && !Error, this way we will not complain if our     buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make     sure we have a fully in-cache block while we're messing with it. (CVE-2022-48902)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - btrfs如果设置了 PageError则不执行 WARN_ON() 如果我们在非最新页面上操作则每当执行任何范围缓冲区操作时我们都会调用 assert_eb_page_uptodate() 来抱怨。我们的夜间测试在这周初发现了此警告 WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: GW 5.17。 0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP 0018ffffa961440a7c68 EFLAGS00010246 RAX0017ffffc0002112 RBXffffe6e74453f9c0 RCX0000000000001000 RDXfffffe6e74467c887 RSI
    ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14:
     R150000000001500000  : 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3:
    0000000118be8004 CR4: 0000000000370ee0 调用跟踪extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 rcu_read_lock_sched_held+0x12/0x60 rcu_read_lock_sched_held+0x12/0x60 lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 此问题已由 c2e39305299f01btrfs当写入失败时清除最新的范围缓冲区部分修复但是该修复所做的只是在写出失败后无法查找范围缓冲区。它没有阻止我们继续使用已找到的缓冲区。在本例中，我们搜索提交根以缓存区块群组，以便可以开始提交事务并切换提交根，然后开始写入。切换后我们可以查找尚未写入的盘区缓冲区并开始处理该区块组。然后我们无法写入该阻止并清除页面上的 Uptodate然后我们开始喷出这些错误。
    通常我们会在一定程度上受到树锁的保护。如果读取了一个区块我们会锁定该区块读取并且在提交写入之前阻止写入者锁定该区块。但是这并不能保证万无一失因为读取可能在执行 submit_bio 之前以及锁定并解锁范围缓冲区之后发生。同样在这种特殊情况下我们设置了 path->skip_locking因此这不会将我们保存在此处。我们将简单地获取一个在读取时有效但在使用时变为无效的区块。我们真正想要的是捕获已读取区块但未将其标记为 Uptodate 的情况。读取时我们执行 ClearPageError()因此如果出现 !Uptodate 和 !Error 则表示读取页面时错误。通过检查 !Uptodate && !Error 来修复此问题这样如果缓冲区在使用时变得无效我们就不会抱怨并且我们将维护检查的本质即确保缓冲区完全在缓存中在我们摆乱它时阻断它。 (CVE-2022-48902)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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

  - btrfs如果我們已設定 PageError則不發出 WARN_ON() 每當我們執行任何範圍緩衝區作業時我們都會呼叫 assert_eb_page_uptodate() 來高聲抱怨如果我們是在非最新頁面上操作。我們的夜間測試在這週稍早發現了這個警告警告fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 的 CPU: 1 PID: 553508 CPU: 1 PID: 553508 Comm: kworker/u4:13 污染的 GW 5.17。 0-rc3+ #564 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.13.0-2.fc32 04/01/2014 工作佇列btrfs-cache btrfs_work_helper RIP0010:assert_eb_page_uptodate+0x3f/0x50 RSP 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDXffffe6e74467c887 RSI
    ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14:
     R150000000001500000  : 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3:
    0000000118be8004 CR4: 0000000000370ee0 呼叫追踪 extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 rcu_read_lock_sched_held+0x12/0x60 rcu_read_lock_sched_held+0x12/0x60 rcu_read_lock_sched_held+0x12/0x60 lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 這已由 c2e39305299f01 部分修正 (btrfs當我們無法寫入時清除最新的範圍緩衝區)但是該修正所做的只是讓我們在失敗的寫出後找不到範圍緩衝區。它不會阻止我們繼續使用已找到的緩衝區。在此情況下我們搜尋提交 root 以快取區塊群組因此我們可以開始提交交易並切換提交 root然後開始寫入。在切換之後我們可以查閱尚未寫入的範圍緩衝區並開始處理該區塊群組。然後我們無法寫入該區塊並清除頁面上的 Uptodate然後我們便開始湧現這些錯誤。
    通常我們在這裡受到某種程度的樹狀結構鎖定保護。如果我們讀取一個區塊我們會鎖定該區塊讀取並且我們會阻止寫入器在我們提交該區塊進行寫入之前鎖定該區塊。然而這不一定是萬無一失的因為讀取可能發生在我們執行 submit_bio 之前以及我們鎖定和解除鎖定範圍緩衝區之後。此外在此特定情況下我們已設定 path->skip_locking因此此處不會將我們儲存。我們只會取得在讀取時有效但在使用時變成無效的區塊。我們真正想要的是捕捉已讀取區塊但其未標記為 Uptodate 的情況。讀取時會出現 ClearPageError()因此如果是 !Uptodate 和 !Error我們就知道我們未採取正確的方式來讀取頁面。透過檢查 !Uptodate && !Error 來修正此問題如此一來我們在使用緩衝區時不會提出投訴而且我們會維持檢查的原則以確保我們有完整的內部快取在我們亂搞時封鎖。 (CVE-2022-48902)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
225193	Linux Distros のパッチ未適用の脆弱性: CVE-2022-48902	Nessus	Misc.	2025/3/5	2025/9/5	medium
225193	Linux Distros Unpatched Vulnerability : CVE-2022-48902	Nessus	Misc.	2025/3/5	2025/9/5	medium
225193	Linux Distros 未修补的漏洞：CVE-2022-48902	Nessus	Misc.	2025/3/5	2025/9/5	medium
225193	Linux Distros 未修補的弱點：CVE-2022-48902	Nessus	Misc.	2025/3/5	2025/9/5	medium

检测

插件搜索

medium

medium

medium

medium