In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
uprobes\/x86: Move optimized uprobe from nop5 to nop10<\/p>\n
Andrii reported an issue with optimized uprobes [1] that can clobber
\nredzone area with call instruction storing return address on stack
\nwhere user code may keep temporary data without adjusting rsp.<\/p>\n
Fixing this by moving the optimized uprobes on top of 10-bytes nop
\ninstruction, so we can squeeze another instruction to escape the
\nredzone area before doing the call, like:<\/p>\n
lea -0x80(%rsp), %rsp
\n call tramp<\/p>\n
Note the lea instruction is used to adjust the rsp register without
\nchanging the flags.<\/p>\n
We use nop10 and following transformation to optimized instructions
\nabove and back as suggested by Peterz [2].<\/p>\n
Optimize path (int3_update_optimize):<\/p>\n
1) Initial state after set_swbp() installed the uprobe:
\n cc 2e 0f 1f 84 00 00 00 00 00<\/p>\n
From offset 0 this is INT3 followed by the tail of the original
\n 10-byte NOP.<\/p>\n
After a previous unoptimization bytes 5..9 may still contain the
\n old call instruction, which remains valid for threads already there.<\/p>\n
2) Rewrite the LEA tail and call displacement:
\n cc [8d 64 24 80 e8 d0 d1 d2 d3]<\/p>\n
From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not
\n executable entry points while byte 0 is trapped.<\/p>\n
3) Publish the first LEA byte:
\n [48] 8d 64 24 80 e8 d0 d1 d2 d3<\/p>\n
From offset 0 this is:
\n lea -0x80(%rsp), %rsp
\n call <\/p>\n
Unoptimize path (int3_update_unoptimize):<\/p>\n
1) Initial optimized state:
\n 48 8d 64 24 80 e8 d0 d1 d2 d3
\n Same as 3) above.<\/p>\n
2) Trap new entries before restoring the NOP bytes:
\n [cc] 8d 64 24 80 e8 d0 d1 d2 d3<\/p>\n
From offset 0 this traps. A thread that had already executed the
\n LEA can still reach the intact CALL at offset 5.<\/p>\n
3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped
\n and byte 5 as CALL.
\n cc [2e 0f 1f 84] e8 d0 d1 d2 d3<\/p>\n
From offset 0 this still traps. Offset 5 is still the CALL for any
\n thread that was already past the first LEA byte.<\/p>\n
4) Publish the first byte of the original NOP:
\n [66] 2e 0f 1f 84 e8 d0 d1 d2 d3<\/p>\n
From offset 0 this is the restored 10-byte NOP; the CALL opcode and
\n displacement are now only NOP operands. Offset 5 still decodes as
\n CALL for a thread that was already there.<\/p>\n
Tthere is only a single target uprobe-trampoline for the given nop10
\n instruction address, so the CALL instruction will not be changed across
\n unoptimization\/optimization cycles.
\n Therefore, any task that is preempted at the CALL instruction is guaranteed
\n to observe that CALL and not anything else.<\/p>\n
Note as explained in [2] we need to use following nop10:
\n PF1 PF2 ESC NOPL MOD SIB DISP32
\nNOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 — cs nopw 0x00000000(%rax,%rax,1)<\/p>\n
which means we need to allow 0x2e prefix which maps to INAT_PFX_CS
\nattribute in is_prefix_bad function.<\/p>\n
Also changing the uprobe syscall error when called out of uprobe
\ntrampoline to -EPROTO, so we are able to detect the fixed kernel.<\/p>\n
The optimized uprobe performance stays the same:<\/p>\n
uprobe-nop : 3.129 \u00b1 0.013M\/s
\n uprobe-push : 3.045 \u00b1 0.006M\/s
\n uprobe-ret : 1.095 \u00b1 0.004M\/s
\n –> uprobe-nop10 : 7.170 \u00b1 0.020M\/s
\n uretprobe-nop : 2.143 \u00b1 0.021M\/s
\n uretprobe-push : 2.090 \u00b1 0.000M\/s
\n uretprobe-ret : 0.942 \u00b1 0.000M\/s
\n –> uretprobe-nop10: 3.381 \u00b1 0.003M\/s
\n usdt-nop : 3.245 \u00b1 0.004M\/s
\n –> usdt-nop10 : 7.256 \u00b1 0.023M\/s<\/p>\n
[1] https:\/\/lore.kernel.org\/bpf\/20260509003146.976844-1-andrii@kernel.org\/
\n[2] https:\/\/lore.kernel.org\/bpf\/20260518104306.GU3102624@noisy.programming.kicks-ass.net\/#t<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
uprobes\/x86: Move optimized uprobe from nop5 to nop10<\/p>\n
Andrii reported an issue with optimized uprobes [1] that can clobber
\nredzone<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-26021","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/26021","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=26021"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=26021"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=26021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}