Possible user-space DoS on Linux when running on an ARM7 CPU in just two instructions. Would that be a record? If the kernel was configured to support OABI (exclusively or together with EABI), I think the following two-ARM-instr binary will simply crash the kernel if the core has alignment checking: SUB PC, PC, #2; SWI 0. I am not sure how common such configs are, but someone should maybe fix that? The fix would be only one extra instruction.
https://lkml.org/lkml/2024/12/4/503 states that OABI support is quite obscure these days and will probably be outright unbuildable at some time in the future, but what you've found still qualifies as a (likely minor) security issue that should be properly reported as such. The kernel page on security reporting is https://docs.kernel.org/process/security-bugs.html
Hai there, kernel guys. Now... assuming you first rob a museum for a working ARM7TDMI-based board, then find a way to flash it with a kernel and a rootfs to boot it, and if your kernel has an obscure and not-used-anymore ABI enabled, and you then somehow give an untrusted party ability to run code on it, they could crash the kernel using this 8-byte userspace binary.
:)
It is academically cool, no more. Quite possibly some old industrial control stuff is still running on old ARM7 boards with OABI enabled, but (i hope) they are not exposed to third party code. I guess I could send in the one line patch, if i find the time. The fix is quite trivial, funnily enough. You simply mask off the bottom 2 bits instead of assuming that LR in ARM mode is 4-byte-aligned, since on ARM7 it might not be
6502 can do it in one. 12 opcodes are glitched in a way that permanently halts the CPU, by causing it to never reset the internal tick counter (...sortof) that starts the next instruction. Recovery is only possible with a power cycle.
