CVE-2024-50099
Publication date:
05/11/2024
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
arm64: probes: Remove broken LDR (literal) uprobe support<br />
<br />
The simulate_ldr_literal() and simulate_ldrsw_literal() functions are<br />
unsafe to use for uprobes. Both functions were originally written for<br />
use with kprobes, and access memory with plain C accesses. When uprobes<br />
was added, these were reused unmodified even though they cannot safely<br />
access user memory.<br />
<br />
There are three key problems:<br />
<br />
1) The plain C accesses do not have corresponding extable entries, and<br />
thus if they encounter a fault the kernel will treat these as<br />
unintentional accesses to user memory, resulting in a BUG() which<br />
will kill the kernel thread, and likely lead to further issues (e.g.<br />
lockup or panic()).<br />
<br />
2) The plain C accesses are subject to HW PAN and SW PAN, and so when<br />
either is in use, any attempt to simulate an access to user memory<br />
will fault. Thus neither simulate_ldr_literal() nor<br />
simulate_ldrsw_literal() can do anything useful when simulating a<br />
user instruction on any system with HW PAN or SW PAN.<br />
<br />
3) The plain C accesses are privileged, as they run in kernel context,<br />
and in practice can access a small range of kernel virtual addresses.<br />
The instructions they simulate have a range of +/-1MiB, and since the<br />
simulated instructions must itself be a user instructions in the<br />
TTBR0 address range, these can address the final 1MiB of the TTBR1<br />
acddress range by wrapping downwards from an address in the first<br />
1MiB of the TTBR0 address range.<br />
<br />
In contemporary kernels the last 8MiB of TTBR1 address range is<br />
reserved, and accesses to this will always fault, meaning this is no<br />
worse than (1).<br />
<br />
Historically, it was theoretically possible for the linear map or<br />
vmemmap to spill into the final 8MiB of the TTBR1 address range, but<br />
in practice this is extremely unlikely to occur as this would<br />
require either:<br />
<br />
* Having enough physical memory to fill the entire linear map all the<br />
way to the final 1MiB of the TTBR1 address range.<br />
<br />
* Getting unlucky with KASLR randomization of the linear map such<br />
that the populated region happens to overlap with the last 1MiB of<br />
the TTBR address range.<br />
<br />
... and in either case if we were to spill into the final page there<br />
would be larger problems as the final page would alias with error<br />
pointers.<br />
<br />
Practically speaking, (1) and (2) are the big issues. Given there have<br />
been no reports of problems since the broken code was introduced, it<br />
appears that no-one is relying on probing these instructions with<br />
uprobes.<br />
<br />
Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW<br />
(literal), limiting the use of simulate_ldr_literal() and<br />
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR<br />
(literal) and LDRSW (literal) will be rejected as<br />
arm_probe_decode_insn() will return INSN_REJECTED. In future we can<br />
consider introducing working uprobes support for these instructions, but<br />
this will require more significant work.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025
