ARM v8.3a pauth not working

Bug #1859713 reported by Adrien Grassein
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Richard Henderson

Bug Description

Host: Ubuntu 19.10 - x86_64 machine
QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)

ARMV8.3 pauth is not working well.

With a test code containing two pauth instructions:
    - paciasp that sign LR with A key and sp as context;
    - autiasp that verify the signature.

Test:
    - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664)

Expected:
    - autiasp places an invalid pointer in LR

Result:
    - autiasp successfully auth the pointer and places 0x0400660 in LR.

Further explanations:
    Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating.
    With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
    With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
    Values of top_bit and bottom_bit are strictly the same and it should not.

Tags: arm

CVE References

Richard Henderson (rth)
Changed in qemu:
assignee: nobody → Richard Henderson (rth)
status: New → Confirmed
Revision history for this message
Vincent Dehors (vdehors) wrote :

Hi,

Here is a patch for this bug. The sbox function was using "b+=16" instead of "b+=4".

Also, you check test vector using :

```c
    uint64_t P = 0xfb623599da6e8127ull;
    uint64_t T = 0x477d469dec0b8762ull;
    uint64_t w0 = 0x84be85ce9804e94bull;
    uint64_t k0 = 0xec2802d4e0a488e9ull;
    ARMPACKey key = { .hi = w0, .lo = k0 };
    uint64_t C5 = pauth_computepac(P, T, key);
    /* C5 should be 0xc003b93999b33765 */
```

Revision history for this message
Richard Henderson (rth) wrote :

Ooof. Good catch on the sbox error.

That said, how did you test pauth_computepac?
I still do not get the C5 result above, but 0x99d88f4472f3be39.

The following test case sets up the parameters.

Revision history for this message
Richard Henderson (rth) wrote :

Oops again. The test case has the parts of the key the wrong way around.
I'll submit the pair of patches to the mailing list.

Revision history for this message
Richard Henderson (rth) wrote :

Now upstream as commit de0b1bae6461f67243282555475f88b2384a1eb9.

Changed in qemu:
status: Confirmed → Fix Committed
Changed in qemu:
status: Fix Committed → Fix Released
Revision history for this message
Philippe Mathieu-Daudé (philmd) wrote :

Apparently this fixed bug is the official CVE-2020-10702:
https://security-tracker.debian.org/tracker/CVE-2020-10702

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.