In the Linux kernel, the following vulnerability has been resolved:
arm64: ptrace: fix partial SETREGSET for NTARMPOE
Currently poeset() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.porel0, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism.
Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NTPRSTATUS, NTPRFPREG, NTARMSYSTEMCALL). In the case of a zero-length write, the existing contents of POREL1 will be retained.
Before this patch:
| # ./poe-test | Attempting to write NTARMPOE::porel0 = 0x900d900d900d900d | SETREGSET(nt=0x40f, len=8) wrote 8 bytes | | Attempting to read NTARMPOE::porel0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NTARMPOE::porel0 = 0x900d900d900d900d | | Attempting to write NTARMPOE (zero length) | SETREGSET(nt=0x40f, len=0) wrote 0 bytes | | Attempting to read NTARMPOE::porel0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NTARMPOE::por_el0 = 0xffff8000839c3d50
After this patch:
| # ./poe-test | Attempting to write NTARMPOE::porel0 = 0x900d900d900d900d | SETREGSET(nt=0x40f, len=8) wrote 8 bytes | | Attempting to read NTARMPOE::porel0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NTARMPOE::porel0 = 0x900d900d900d900d | | Attempting to write NTARMPOE (zero length) | SETREGSET(nt=0x40f, len=0) wrote 0 bytes | | Attempting to read NTARMPOE::porel0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NTARMPOE::por_el0 = 0x900d900d900d900d