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

  - binder修复与 munmap() 争用的 alloc->vma 的 UAF 在提交 720c24192404 中binder将 down_write 更改为 down_readbinder 假设 mmap 读取锁定足以保护 binder_update_page_range() 内的 alloc->vma。在提交 dd2283f2605e mmapmunmap 中包含读取 mmap_sem 的 zap 页面之前这通常是准确的现在可在将 vma 从 munmap() 中的 rbtree 分离后降级 mmap_lock。然后继续拆卸并释放仅保持读取锁定的 vma。这意味着访问 binder_update_page_range() 中的 alloc->vma 现在将与 munmap() 中的 vm_area_free() 争用并可造成 UAF，如以下 KASAN 跟踪所示
    ================================================== ================ 缺陷KASAN通过任务 server/558 CPU: 3 PID: 558 Comm在地址 ffff16204ad00600 发生的大小 8 的 vm_insert_page+0x7c/0x1f0 读取中存在释放后使用其他
    服务器 未受感染 5.10.150-00001-gdc8dcf942daa #1 硬件名称linux,dummy-virt (DT) 调用跟踪
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction +0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由任务分配 559:
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common .constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由任务 560 释放
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc +0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ========================== ======================================== 若要防止上述争用请将binder_update_page_range() 内的 mmap 写入锁定。mmap 锁争用可能会增加。但是 binder 已通过顶层 alloc->mutex 序列化了这些调用。此外运行 binder 基准测试时未显示出任何性能影响。请注意此修补程序特定于稳定分支 5.4 和 5.10。较新的内核版本 以来 binder 不再缓存指向 vma 的指针。相反它已重构为使用 vma_lookup()从而避免了此处所述的问题。此开关在提交 a43cfc87caaf (androidbinder停止将指针保存到 VMA) 中引入。 (CVE-2022-50240)

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

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

  - binder: fix UAF of alloc->vma in race with munmap() In commit 720c24192404 (ANDROID: binder: change     down_write to down_read) binder assumed the mmap read lock is sufficient to protect alloc->vma inside     binder_update_page_range(). This used to be accurate until commit dd2283f2605e (mm: mmap: zap pages with     read mmap_sem in munmap), which now downgrades the mmap_lock after detaching the vma from the rbtree in     munmap(). Then it proceeds to teardown and free the vma with only the read lock held. This means that     accesses to alloc->vma in binder_update_page_range() now will race with vm_area_free() in munmap() and can     cause a UAF as shown in the following KASAN trace:
    ================================================================== BUG: KASAN: use-after-free in     vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm:
    server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164     print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4     vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0     binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c     el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0     vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c     ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270     do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560:
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c     remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64     el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114     el0_sync+0x180/0x1c0 [...] ================================================================== To prevent     the race above, revert back to taking the mmap write lock inside binder_update_page_range(). One might     expect an increase of mmap lock contention. However, binder already serializes these calls via top level     alloc->mutex. Also, there was no performance impact shown when running the binder benchmark tests. Note     this patch is specific to stable branches 5.4 and 5.10. Since in newer kernel releases binder no longer     caches a pointer to the vma. Instead, it has been refactored to use vma_lookup() which avoids the issue     described here. This switch was introduced in commit a43cfc87caaf (android: binder: stop saving a pointer     to the VMA). (CVE-2022-50240)

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

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

  - バインタ munmap() との競合での alloc->vma の UAF を修正します ANDROIDバインディングdown_write を down_read へ変更バインディングは、mmap の読み取りロックが bind_update_page_range() 内の alloc->vma を保護するのに十分であることを前提としていました。これは、dd2283f2605e がコミットされるまで正確でした。mmap_sem を munmap で読み取る zap ページ。現在は、munmap() で rbtree から vma をデタッチした後に、mmap_lock をダウングレードします。次に、読み取りロックのみを保持した状態で、vma をティアダウンして解放します。これは、binder_update_page_range() の alloc->vma へのアクセスが munmap() の vm_area_free() と競合するようになり、次の KASAN トレースに示されているように、UAF を引き起こす可能性があることを意味します。
    ======================================================== =================== バグ KASANタスクサーバー/558 による vm_insert_page+0x7c/0x1f0 での use-after-free。addr ffff16204ad00600 でのサイズ 8 の読み取り CPU3 PID558 通信:
    サーバーは汚染されていない 5.10.150-00001-gdc8dcf942daa #1 ハードウェア名linux、dummy-virtDTコールトレース
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction +0x64c/0x3040roled_thread_write+0x924/0x2020binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c00000000000000000000000000000000000000000000000000000000000000000000000000 https
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common .constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 タスク 560 により解放されます
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc +0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ============================ ======================================================================================================================================================================================================================================================================================================== === Patching_update_page_range() 内の mmap 書き込みロック。mmap ロックコンテンションの増加が予想されます。ただし、binder ではこれらの呼び出しをトップレベルの alloc->mutex を通じてすでにシリアル化しています。また、バインディングベンチマークテストの実行時のパフォーマンスへの影響も示されませんでした。注このパッチは、安定版stableブランチ 5.4 および 5.10に固有のものです。新しいカーネルリリース以降、binder は vma に対するポインターをキャッシュしなくなりました。代わりに、ここで説明されている問題を回避する vma_lookup() を使用するようにリファクタリングされています。このスイッチは、a43cfc87caaf というコミットで導入されましたandroidバインダーVMA へのポインターの保存を停止します。CVE-2022-50240

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

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

  - binder修正 alloc->vma 在與 munmap() 爭用中的 UAF 在認可 720c24192404 中 (ANDROIDbinder將 down_write 變更為 down_read) binder 假設 mmap 讀取鎖定足以保護 binder_update_page_range() 內的 alloc->vma。這在提交 dd2283f2605e 之前都是正確的 (mmmap在 munmap 中具有讀取 mmap_sem 的 zap 頁面)現在在 munmap() 中將 vma 從 rbtree 卸離之後會降級 mmap_lock。然後在保留讀取鎖定的情況下繼續卸除並釋放 vma。這表示對 binder_update_page_range() 中的 alloc->vma 的存取現在會與 munmap() 中的 vm_area_free() 爭用且可造成如下列 KASAN 追踪所示的 UAF
    ================================================== ================ 錯誤KASAN在 vm_insert_page+0x7c/0x1f0 中發生釋放後使用錯誤。讀取位於位址 ffff16204ad00600 執行的作業 server/558 CPU: 3 PID: 558 Comm在
    伺服器 未受污染的 5.10.150-00001-gdc8dcf942daa #1 硬體名稱linux,dummy-virt (DT) 呼叫追踪
    dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction +0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c
    __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 由 5x0_stack 工作配置
    __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common .constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 已由工作 560 釋放
    kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c
    __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc +0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ========================== ======================================== 若要防止上述爭用情形請回復為採取binder_update_page_range() 中的 mmap 寫入鎖定。預期 mmap 鎖定爭用可能有所增加。不過binder 已透過頂層 alloc->mutex 序列化這些呼叫。此外執行資料夾基準測試時不會顯示任何效能影響。請注意此修補程式專用於穩定分支 5.4 和 5.10。由於在較新的核心版本中資料夾不再快取 vma 的指標。而是重構為使用 vma_lookup()可避免此處所述的問題。此切換是在認可 a43cfc87caaf 中引入 (androidbinder停止儲存 VMA 的指標)。 (CVE-2022-50240)

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

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

Detections

Analytics

Plugins Search

medium

medium

medium

medium