blob: 5e2cabd9cca503d175463ab7e401d8977cde4e4d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
other: 0.855
graphic: 0.843
permissions: 0.714
device: 0.705
performance: 0.667
socket: 0.667
network: 0.662
PID: 0.660
debug: 0.617
files: 0.563
vnc: 0.516
semantic: 0.508
boot: 0.465
KVM: 0.401
Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault)
I've come across a very specific situation, but I'm sure it could be replicated in other cases.
In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs.
I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted.
This is a compiler bug affecting (at least) libcrypto.so.1.1:
179d90: d503233f paciasp
179d94: a9bb7bfd stp x29, x30, [sp, #-80]!
...
17a400: d50323bf autiasp
17a404: f84507fd ldr x29, [sp], #80
17a408: d65f03c0 ret
The PAC happens with the initial sp:
X30=0000005501de55fc SP=00000055018477a0
while the AUTH happens with the decremented sp:
X30=0011005501de55fc SP=0000005501847750
Since the salt (sp) is different for the two operations, the
authorization should and does fail:
X30=0020005501de55fc
Note bit 53 is now set in x30, which is the error indication.
The compiler must move the authiasp down below the ldr pop.
|