Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%

CVE-2024-26987— mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled

AI Predicted 3.3 Difficulty: Moderate EPSS 0.18% · P7

Affected Version Matrix 10

VendorProductVersion RangeStatus
LinuxLinuxa6b40850c442bf996e729e1d441d3dbc37cea171< 5ef7ba2799a3b5ed292b8f6407376e2c25ef002eaffected
a6b40850c442bf996e729e1d441d3dbc37cea171< 882e1180c83f5b75bae03d0ccc31ccedfe5159deaffected
a6b40850c442bf996e729e1d441d3dbc37cea171< 49955b24002dc16a0ae2e83a57a2a6c863a1845caffected
a6b40850c442bf996e729e1d441d3dbc37cea171< 1983184c22dd84a4d95a71e5c6775c2638557dc7affected
5.18affected
< 5.18unaffected
6.1.88≤ 6.1.*unaffected
6.6.29≤ 6.6.*unaffected
… +2 more rows
Get alerts for future matching vulnerabilitiesLog in to subscribe

I. Basic Information for CVE-2024-26987

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 In short, below scene breaks the ---truncated---
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于启用hugetlb_optimize_vmemmap时出现死锁问题。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

VendorProductAffected VersionsCPESubscribe
LinuxLinux a6b40850c442bf996e729e1d441d3dbc37cea171 ~ 5ef7ba2799a3b5ed292b8f6407376e2c25ef002e -
LinuxLinux 5.18 -

II. Public POCs for CVE-2024-26987

#POC DescriptionSource LinkShenlong Link
AI-Generated POCPremium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2024-26987

登录查看更多情报信息。

Patches & Fixes for CVE-2024-26987 (1)

Mailing List Discussions for CVE-2024-26987 (3)

Other References for CVE-2024-26987 (3)

Same Patch Batch · Linux · 2024-05-01 · 159 CVEs total

CVE-2024-273889.8 CRITICALSUNRPC: fix some memleaks in gssx_dec_option_array
CVE-2024-269539.8 CRITICALnet: esp: fix bad handling of pages from page_pool
CVE-2024-269318.8 HIGHscsi: qla2xxx: Fix command flush on cable pull
CVE-2024-269908.8 HIGHKVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status
CVE-2024-270538.8 HIGHwifi: wilc1000: fix RCU usage in connect path
CVE-2024-269528.3 HIGHksmbd: fix potencial out-of-bounds when buffer offset is invalid
CVE-2024-270188.2 HIGHnetfilter: br_netfilter: skip conntrack input hook for promisc packets
CVE-2024-269368.2 HIGHksmbd: validate request buffer size in smb2_allocate_rsp_buf()
CVE-2024-269808.2 HIGHksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
CVE-2024-269548.1 HIGHksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
CVE-2024-269947.8 HIGHspeakup: Avoid crash on very long word
CVE-2024-269667.8 HIGHclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
CVE-2024-269747.8 HIGHcrypto: qat - resolve race condition during AER recovery
CVE-2024-269767.8 HIGHKVM: Always flush async #PF workqueue when vCPU is being destroyed
CVE-2024-270627.8 HIGHnouveau: lock the client object tree.
CVE-2024-270617.8 HIGHcrypto: sun8i-ce - Fix use after free in unprepare
CVE-2024-269837.8 HIGHbootconfig: use memblock_free_late to free xbc memory to buddy
CVE-2024-270587.8 HIGHtmpfs: fix race on handling dquot rbtree
CVE-2024-270567.8 HIGHwifi: iwlwifi: mvm: ensure offloading TID queue exists
CVE-2024-270177.8 HIGHnetfilter: nft_set_pipapo: walk over current view on netlink dump

Showing top 20 of 159 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2024-26987

No comments yet


Leave a comment