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

  - btrfs: fix deadlock between concurrent dio writes when low on free data space When reserving data space     for a direct IO write we can end up deadlocking if we have multiple tasks attempting a write to the same     file range, there are multiple extents covered by that file range, we are low on available space for data     and the writes don't expand the inode's i_size. The deadlock can happen like this: 1) We have a file with     an i_size of 1M, at offset 0 it has an extent with a size of 128K and at offset 128K it has another extent     also with a size of 128K; 2) Task A does a direct IO write against file range [0, 256K), and because the     write is within the i_size boundary, it takes the inode's lock (VFS level) in shared mode; 3) Task A locks     the file range [0, 256K) at btrfs_dio_iomap_begin(), and then gets the extent map for the extent covering     the range [0, 128K). At btrfs_get_blocks_direct_write(), it creates an ordered extent for that file range     ([0, 128K)); 4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file range [0, 256K); 5)     Task A executes btrfs_dio_iomap_begin() again, this time for the file range [128K, 256K), and locks the     file range [128K, 256K); 6) Task B starts a direct IO write against file range [0, 256K) as well. It also     locks the inode in shared mode, as it's within the i_size limit, and then tries to lock file range [0,     256K). It is able to lock the subrange [0, 128K) but then blocks waiting for the range [128K, 256K), as it     is currently locked by task A; 7) Task A enters btrfs_get_blocks_direct_write() and tries to reserve data     space. Because we are low on available free space, it triggers the async data reclaim task, and waits for     it to reserve data space; 8) The async reclaim task decides to wait for all existing ordered extents to     complete (through btrfs_wait_ordered_roots()). It finds the ordered extent previously created by task A     for the file range [0, 128K) and waits for it to complete; 9) The ordered extent for the file range [0,     128K) can not complete because it blocks at btrfs_finish_ordered_io() when trying to lock the file range     [0, 128K). This results in a deadlock, because: - task B is holding the file range [0, 128K) locked,     waiting for the range [128K, 256K) to be unlocked by task A; - task A is holding the file range [128K,     256K) locked and it's waiting for the async data reclaim task to satisfy its space reservation request; -     the async data reclaim task is waiting for ordered extent [0, 128K) to complete, but the ordered extent     can not complete because the file range [0, 128K) is currently locked by task B, which is waiting on task     A to unlock file range [128K, 256K) and task A waiting on the async data reclaim task. This results in a     deadlock between 4 task: task A, task B, the async data reclaim task and the task doing ordered extent     completion (a work queue task). This type of deadlock can sporadically be triggered by the test case     generic/300 from fstests, and results in a stack trace like the following: [12084.033689] INFO: task     kworker/u16:7:123749 blocked for more than 241 seconds. [12084.034877] Not tainted 5.18.0-rc2-btrfs-     next-115 #1 [12084.035562] echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message.
    [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000 [12084.036554]     Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] Call Trace: [12084.036601] <TASK>     [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620]     btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0     [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400     [btrfs] [12084.0367 ---truncated--- (CVE-2022-49547)

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

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

  - btrfs空きデータ空間が少ない場合、同時 dio 書き込みの間のデッドロックを修正します。直接 IO 書き込みのためにデータ空間を予約する際、同じファイル範囲への書き込みを試行する複数のタスクがある場合、デッドロックに陥る可能性があります。同じファイル範囲への書き込みを試行する複数のタスクがある場合、ファイル範囲の中で、データ用の利用可能な空間が少なく、書き込みによって inode の i_size が拡張されません。デッドロックは次のように発生する可能性があります。1) i_size が 1M のファイルがあり、オフセット 0 にはサイズが 128K のエクステントがあり、オフセット 128K にはサイズが 128K の他のエクステントがあります。 2) タスク A は、ファイル範囲 [0, 256K] に対して直接 IO 書き込みを行います。書き込みは i_size 境界内にあるため、共有モードで inode のロックVFS レベルに従います。 3) タスク A は btrfs_dio_iomap_begin() でファイル範囲 [0, 256K) をロックした後、範囲 [0, 128K] をカバーするエクステントマップを取得します。btrfs_get_blocks_direct_write() で、そのファイル範囲 ([0, 128K)] に対して順序付けられたエクステントを作成します。 4) btrfs_dio_iomap_begin() から戻る前に、ファイル範囲 [0, 256K) をロック解除します。 5) タスク A が再度 btrfs_dio_iomap_begin() を実行し、今回はファイル範囲 [128K, 256K] に対して再度実行し、ファイル範囲 [128K, 256K] をロックします。 6) タスク B もファイル範囲 [0、256K) に対して直接 IO 書き込みを開始します。また、i_size の制限内であるため、共有モードで inode をロックしてから、ファイル範囲 [0, 256K) のロックを試みます。サブ範囲 [0, 128K] をロックできますが、現在タスク A によってロックされているため、範囲 [128K, 256K]のためにブロック待機します。 7) タスク A が btrfs_get_blocks_direct_write() に入り、データ領域の予約を試みます。使用できる空き領域が不足しているため、非同期データ再請求タスクをトリガーし、データ領域が予約されるのを待ちます。 8) async reclaim タスクは、既存のすべての順序付けられたエクステントが完了するまで待機することを決定しますbtrfs_wait_ordered_roots() により。ファイル範囲 [0, 128K) に対してタスク A によって以前に作成された、順序付けられたエクステントを見つけ、完了するまで待機します。 9) ファイル範囲 [0、128K] をロックしようとする際に btrfs_finish_ordered_io() でブロックするため、ファイル範囲 [0、128K] の順序付けられたエクステントを完了できません。これにより、デッドロックが発生します。 - タスク B はファイル範囲 [0, 128K) をロックしたまま、範囲 [128K, 256K] がタスク A によってロック解除されるのを待っています。 - タスク A はファイル範囲 [128K、256K) をロックしたまま、スペース予約リクエストを満たすために非同期データ再要求タスクを待っています。 - 非同期データ再要求タスクは、順序付けられたエクステント [0, 128K) の完了を待機していますが、ファイル範囲 [0, 128K) が現在ロックされており、タスク A のロック解除を待機しているため、順序付けられたエクステントが完了しません。ファイル範囲 [128K, 256K] とタスク A が非同期データ再請求タスクを待機しています。これにより、タスク A、タスク B、非同期データ再要求タスク、順序付き範囲完了を実行するタスク (作業キュータスク) の 4 つのタスクの間にデッドロックが発生します。このタイプのデッドロックは、fstests からのテストケース generic/300 によって散発的に発生し、以下のようなスタックトレースを引き起こします。[12084.033689] INFOタスク kworker/u16:7:123749 が 241 秒以上ブロックされました。 [12084.034877] 汚染されていない 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] echo 0 > /proc/sys/kernel/hung_task_timeout_secs はこのメッセージを無効にします。
    [12084.036548] task:kworker/u16:7 state:D stack:0 pid:123749 ppid2 flags:0x0000400012084.036554] ワークキュー btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] コールトレース[12084.036601] <TASK> ] [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0 [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs]12084.0367 ---truncated---CVE-2022-49547

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

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

  - btrfs修复可用数据空间不足时并发 dio 写入之间的死锁当为直接 IO 写入预留数据空间时如果有多个任务尝试写入相同的文件范围我们可能会以死锁结束存在该任务涵盖的多个盘区文件范围内可用于存储数据的空间不足且写入未扩展 inode 的 i_size。死锁可能在以下情况发生1) 一个文件的 i_size 为 1M在偏移 0 处具有大小为 128K 的盘区在偏移 128K 处具有另一个大小也为 128K 的盘区2) 任务 A 对文件范围 [0, 256K) 进行直接 IO 写入且由于写入在 i_size 边界内因此其会在共享模式下锁定 inodeVFS 级别3) 任务 A 在 btrfs_dio_iomap_begin() 中锁定文件范围 [0, 256K)然后获取覆盖范围 [0, 128K) 的盘区的盘区映射。在 btrfs_get_blocks_direct_write() 中为此文件范围创建有序盘区 ([0, 128K)] 4) 在从 btrfs_dio_iomap_begin() 返回之前解锁文件范围 [0, 256K 5) 任务 A 再次针对文件范围 [128K, 256K) 执行 btrfs_dio_iomap_begin()并锁定文件范围 [128K, 256K)； 6) 任务 B 也对文件范围 [0、 256K] 启动直接 IO 写入。它还会锁定共享模式中的 inode因为它在 i_size 限制内然后尝试锁定文件范围 [0, 256K]。它能够锁定子范围 [0, 128K)但随后阻断等待范围 [128K, 256K)因为它当前被任务 A 锁定7) 任务 A 进入 btrfs_get_blocks_direct_write() 并尝试预留数据空间。由于可用空间不足因此它会触发异步数据回收任务并等待其预留数据空间8) 异步回收任务决定等待所有现有有序盘区完成通过 btrfs_wait_ordered_roots()。查找之前由任务 A 为文件范围 [0, 128K) 创建的有序盘区并等待其完成9) 文件范围 [0, 128K) 的排序范围无法完成因为它在尝试锁定文件范围 [0, 128K) 时在 btrfs_finish_ordered_io() 处阻断。这会导致死锁因为: - 任务 B 保持锁定文件范围 [0, 128K)正在等待任务 A 解锁范围 [128K, 256K) - 任务 A 保持文件范围 [128K, 256K) 的锁定并且等待异步数据回收任务满足其空间预留请求- 异步数据回收任务正在等待排序范围 [0, 128K) 完成但排序范围无法完成因为任务 B 当前已锁定文件范围 [0, 128K)而任务 B 正在等待任务 A 解锁文件范围 [128K, 256K) 和任务 A 等待异步数据回收任务。这会导致在 4 个任务之间死锁：任务 A、任务 B、异步数据回收任务和执行有序范围完成的任务（工作队列任务）。fstests 中的测试案例 generic/300 可偶尔触发此类死锁并生成如下所示的堆栈跟踪结果 [12084.033689] INFO任务 kworker/u16:7:123749 阻断超过 241 秒。 [12084.034877] 未受感染 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。
    [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000 [12084.036554] Workqueue btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] 调用跟踪 [12084.036601] <TASK> [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0 [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs] [12084.0367 ---truncated--- (CVE-2022-49547)

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

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

  - btrfs可用資料空間不足時修正並行 dio 寫入之間的鎖死。在為直接 IO 寫入保留資料空間時如果有多個工作嘗試寫入相同的檔案範圍即有多個範圍受其涵蓋檔案範圍內可供儲存資料的空間不足且寫入作業並未擴充 inode 的 i_size。鎖死的情況如下 1) 我們有一個 i_size 為 1M 的檔案在位移 0 處有一個大小為 128K 的範圍而在位移 128K 處有另一個大小也為 128K 的範圍2) 工作 A 針對檔案範圍 [0, 256K) 執行直接 IO 寫入且由於寫入位於 i_size 邊界內因此它會在共用模式下取得 inode 的鎖定 (VFS 層級) 3) 工作 A 鎖定 btrfs_dio_iomap_begin() 的檔案範圍 [0, 256K)然後取得涵蓋範圍 [0, 128K) 的範圍對應。在 btrfs_get_blocks_direct_write() 中它會針對該檔案範圍建立已排序的範圍 ([0, 128K)) 4) 從 btrfs_dio_iomap_begin() 傳回之前其會解除鎖定檔案範圍 [0, 256K) 5) 工作 A 再次執行 btrfs_dio_iomap_begin()這次是針對檔案範圍 [128K、256K)並鎖定檔案範圍 [128K、256K) 6) 工作 B 也會針對檔案範圍 [0, 256K) 啟動直接 IO 寫入。它也會鎖定共用模式下的 inode (因為它位於 i_size 限制內)然後嘗試鎖定檔案範圍 [0, 256K)。其可鎖定子範圍 [0, 128K)但隨後封鎖並等候範圍 [128K, 256K)因為該範圍目前已由工作 A 鎖定7) 工作 A 進入 btrfs_get_blocks_direct_write() 並嘗試保留資料空間。由於可用空間不足因此會觸發非同步資料回收工作並等待其保留資料空間8) async 回收工作決定等待所有現有的已排序範圍完成 (透過 btrfs_wait_ordered_roots())。它會尋找工作 A 先前針對檔案範圍 [0, 128K) 建立的已排序範圍並等待其完成9) 檔案範圍 [0, 128K) 的已排序範圍無法完成因為它在嘗試鎖定檔案範圍 [0, 128K) 時於 btrfs_finish_ordered_io() 封鎖。這會導致鎖死的原因是- 工作 B 鎖定的檔案範圍 [0, 128K) 等待工作 A 解除鎖定範圍 [128K, 256K) - 工作 A 將檔案範圍 [128K、256K) 鎖定並等待非同步資料回收工作滿足其空間保留要求- 非同步資料回收工作正在等待已排序的範圍 [0, 128K) 完成但已排序的範圍無法完成因為檔案範圍 [0, 128K) 目前已由正在任務 A 上解除鎖定的任務 B 目前鎖定檔案範圍 [128K、256K) 以及正在等待非同步資料回收工作的工作 A。這會導致下列 4 個工作鎖死：工作 A、工作 B、非同步資料回收工作以及完成已排序範圍的工作 (工作佇列工作)。fstests 的測試案例 generic/300 偶爾會觸發此類型的鎖死並產生類似下列的堆疊追踪[12084.033689] INFOkworker/u16:7:123749 工作遭到封鎖超過 241 秒。 [12084.034877] 未受污染 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此訊息。
    [12084.036548] task:kworker/u16:7 state:D 堆疊0 pid123749 ppid2 旗標0x00004000 [12084.036554] 工作佇列 btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] 呼叫追踪 [12084.036601] <TASK> [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0 [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs] [12084.0367 ---truncated--- (CVE-2022-49547)

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

ID	Name	Product	Family	Published	Updated	Severity
226055	Linux Distros Unpatched Vulnerability : CVE-2022-49547	Nessus	Misc.	3/5/2025	8/9/2025	medium
226055	Linux Distros のパッチ未適用の脆弱性: CVE-2022-49547	Nessus	Misc.	3/5/2025	8/9/2025	medium
226055	Linux Distros 未修补的漏洞：CVE-2022-49547	Nessus	Misc.	3/5/2025	8/9/2025	medium
226055	Linux Distros 未修補的弱點：CVE-2022-49547	Nessus	Misc.	3/5/2025	8/9/2025	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium