CVE-2024-50099

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.