In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
x86\/alternatives: Exclude text poking against change_page_attr()<\/p>\n
From time to time, the following BUG can be observed
\nin the x86 alternatives patching code [0]:<\/p>\n
> kernel BUG at arch\/x86\/kernel\/alternative.c:2576!
\n > Oops: invalid opcode: 0000 [#1] SMP NOPTI
\n > CPU: 0 UID: 0 PID: 355 Comm: (udev-worker) Not tainted 7.1.3-1-default #1 PREEMPT(full) openSUSE Tumbleweed 8c1795b03ec64f997e57a8ad38b1161e3b98da64
\n > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02\/02\/2022
\n > RIP: 0010:__text_poke+0x2aa\/0x450
\n > Call Trace:
\n >
\n > smp_text_poke_batch_finish+0x2a7\/0x320
\n > __static_call_transform+0xb7\/0x220
\n > arch_static_call_transform+0x5b\/0xb0
\n > __static_call_init+0xe9\/0x270
\n > static_call_module_notify+0x11f\/0x150
\n > notifier_call_chain+0x61\/0xe0
\n > blocking_notifier_call_chain_robust+0x63\/0xc0
\n > load_module+0x1c92\/0x20c0
\n > init_module_from_file+0xd8\/0x140
\n > idempotent_init_module+0x100\/0x2f0
\n > __x64_sys_finit_module+0x71\/0xe0
\n > do_syscall_64+0xe1\/0x610
\n > entry_SYSCALL_64_after_hwframe+0x76\/0x7e<\/p>\n
which matches the following BUG_ON() in alternative.c:<\/p>\n
\t\/*
\n\t * If something went wrong, crash and burn since recovery paths are not
\n\t * implemented.
\n\t *\/
\n\tBUG_ON(!pages[0] || (cross_page_boundary && !pages[1]));<\/p>\n
This can happen if vmalloc_to_page() fails, for any reason. Such can happen
\nif text poking races with CPA, which can possibly result in the collapsing
\nof page tables (or breaking of PMD hugepages). It is not a problem for most
\nusers of vmalloc_to_page() (they solely own the vmalloc’d range) but, when
\nCONFIG_ARCH_HAS_EXECMEM_ROX=y, various modules own a single execmem vmalloc
\nrange, and can call set_memory_*() in parallel on it. This can happen to
\nrace against __text_poke and cause havoc in vmalloc_to_page().<\/p>\n
Fix it by excluding against CPA using the init_mm mmap read lock.<\/p>\n
[ dhansen: Fix up SoB ordering. The actual code flow here was:
\n\t Pedro=>Lorenzo=>Mike=>Me which is reflected in the SoB chain
\n\t now. I *believe* Mike simply picked up Lorenzo’s update to
\n\t Pedro’s post from the Link ]<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
x86\/alternatives: Exclude text poking against change_page_attr()<\/p>\n
From time to time, the following BUG can be observed
\nin the x86 a<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-29098","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/29098","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29098"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29098"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29098"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}