OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds

Bug #1951279 reported by Juan
60
This bug affects 10 people
Affects Status Importance Assigned to Milestone
OpenSSL
Fix Released
Unknown
openssl (Debian)
Fix Released
Unknown
openssl (Ubuntu)
Fix Released
Medium
Unassigned
Focal
Confirmed
Medium
Unassigned

Bug Description

Description
-----------

It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates.

This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc).

Environment and platform
------------------------
Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

Steps to reproduce
------------------

1. Run:

curl -v https://graph.facebook.com/v12.0/act_111/

or

wget https://graph.facebook.com/v12.0/act_111/

Result received
---------------

Segmentation fault (core dumped)

Notes
-----

This bug was found by the Curl users:
See: https://github.com/curl/curl/issues/8024

I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection.

Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment.

Revision history for this message
Juan (juanparati) wrote :

I observed that many users are affected by this bug. (See: https://github.com/curl/curl/issues/8024)

Revision history for this message
Seth Arnold (seth-arnold) wrote :
Download full text (6.4 KiB)

Can you provide more information on your environment and how to reproduce this? I wasn't able to reproduce this on my rpi3b+ running focal, with either libssl1.1 1.1.1f-1ubuntu2.8 or 1.1.1f-1ubuntu2.9:

First, 1.1.1f-1ubuntu2.8 installed:

$ curl -v https://graph.facebook.com/v12.0/act_111/
* Trying 157.240.3.20:443...
* TCP_NODELAY set
* Connected to graph.facebook.com (157.240.3.20) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Menlo Park; O=Facebook, Inc.; CN=*.facebook.com
* start date: Nov 4 00:00:00 2021 GMT
* expire date: Feb 2 23:59:59 2022 GMT
* subjectAltName: host "graph.facebook.com" matched cert's "*.facebook.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xaaaac4c9dee0)
> GET /v12.0/act_111/ HTTP/2
> Host: graph.facebook.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 403
< vary: Origin
< x-ad-account-usage: {"acc_id_util_pct":0}
< x-fb-rlafr: 0
< content-type: application/json; charset=UTF-8
< www-authenticate: OAuth "Facebook Platform" "insufficient_scope" "(#200) Provide valid app ID"
< access-control-allow-origin: *
< facebook-api-version: v12.0
< strict-transport-security: max-age=15552000; preload
< pragma: no-cache
< cache-control: no-store
< expires: Sat, 01 Jan 2000 00:00:00 GMT
< x-fb-request-id: AYFxZKGuw4Uidu_b6_RsyRn
< x-fb-trace-id: C1HBc2Oi1S3
< x-fb-rev: 1004746171
< x-fb-debug: yza+SwSrqD6mY1INQSyb5rcHmU89PziSoE3txYwg1BjWybYcgB36mUMVxq9bsRAJXZGkc34nNcSps5APpyG8QA==
< content-length: 125
< date: Wed, 17 Nov 2021 20:48:02 GMT
< alt-svc: h3=":443"; ma=3600, h3-29=":443"; ma=3600
<
* Connection #0 to host graph.facebook.com left intact
{"error":{"message":"(#200) Provide valid app ID","type":"OAuthException","code":200,"fbtrace_id":"AYFxZKGuw4Uidu_b6_RsyRn"}}ubuntu@ubuntu:~ $ wget https://graph.facebook.com/v12.0/act_111/
--2021-11-17 20:48:16-- https://graph.facebook.com/v12.0/act_111/
Resolving graph.facebook.com (graph.facebook.com)... 157.240.3.20, 2a03:2880:f001:6:face:b00c:0:2
Connecting to graph.facebook.com (graph.facebook.com)|157.240.3.20|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2021...

Read more...

Changed in openssl (Ubuntu):
status: New → Incomplete
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hmm, something else to keep in mind: many aarch64 systems run on SD cards or USB memory sticks and those are notorious garbage.

Is this a reasonable hard drive or is this cheap flash storage? Are there messages in dmesg that might indicate filesystem or block storage errors?

If this isn't a real hard drive then your debugging time is probably better spent replacing the storage as a first effort.

Thanks

Revision history for this message
Hendrawan Kuncoro (pentatonicfunk) wrote :

same issue
my environment is inside docker

------
docker run -it --platform linux/arm64 ubuntu:20.04 /bin/bash

Linux 888c7f7b294c 5.10.47-linuxkit #1 SMP PREEMPT Sat Jul 3 21:50:16 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

curl 7.68.0 (aarch64-unknown-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSocket

------

maybe that will help finding the root cause.

Revision history for this message
Juan (juanparati) wrote :

@Seth: The Ubuntu 20.04 that where I tested this issue was a virtualized environments that runs Parallels Desktop over a Mac OS.

I cannot reproduce this issue on Debian Buster 10 (Arm64) with OpenSSL using the same virtualized environment.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Ah, that's good for the health of your storage :)

Please follow up with the debug symbols and reproduction instructions.

Thanks

Revision history for this message
Juan (juanparati) wrote :

More information about the OpenSSL version:

Package: openssl
Architecture: arm64
Version: 1.1.1f-1ubuntu2.9
Multi-Arch: foreign
Priority: important
Section: utils
Origin: Ubuntu
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Debian OpenSSL Team <email address hidden>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 1213
Depends: libc6 (>= 2.17), libssl1.1 (>= 1.1.1)
Suggests: ca-certificates
Filename: pool/main/o/openssl/openssl_1.1.1f-1ubuntu2.9_arm64.deb
Size: 598980
MD5sum: da89b21f3a0fe0fb5742b406ddcfe3f0
SHA1: 46000c169dc62b33e5a5cf0775597382576de1d3
SHA256: 62ccb4f98929011145f9d49cefa23a21388ee72aab46b304ad05fec6d46d7d2e
SHA512: 27058d8acf628ad2b26926c779c444c7393d44c897f6d23b97c7fc89ae4b0af7dd6ef8d9c28d0aca87fde107235da
940c8a0cb068e5274d87776c44ecd9e399a

Revision history for this message
Juan (juanparati) wrote :

Another more accurate way of reproduce this bug:

Execute:

openssl s_client -showcerts -connect graph.facebook.com:443 </dev/null

Result:

CONNECTED(00000003)
[1] 4427 segmentation fault openssl s_client -showcerts -connect graph.facebook.com:443 < /dev/null

Revision history for this message
Juan (juanparati) wrote :

I installed the debug symbols and run OpenSSL however GDB is not returned valuable information about the backtrace.

This is what I received:

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from openssl...
Reading symbols from /usr/lib/debug/.build-id/a2/f3e269767a7410ab51fafa0461e7f051144517.debug...
(gdb) run s_client -showcerts -connect graph.facebook.com:443
Starting program: /usr/bin/openssl s_client -showcerts -connect graph.facebook.com:443
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
CONNECTED(00000003)

Program received signal SIGSEGV, Segmentation fault.
0x0020fffff7e0809c in ?? ()
(gdb) bt
#0 0x0020fffff7e0809c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 0
#0 0x0020fffff7e0809c in ?? ()

Revision history for this message
Bento (bdg01) wrote :

I am encountering the same issue. IMHO there needs to be a newer OpenSSL release for 20.04 LTS included in the repos.

Revision history for this message
Craig Anderson (intrepidws) wrote :

I have the same issue. It's preventing me from doing some fairly important things, without an obvious workaround at the moment.

Revision history for this message
Bento (bdg01) wrote :

 1.1.1f-1ubuntu2.09 was just updated in the repos to 1.1.1f-1ubuntu2.10 but no fix for this issue yet :-(

Revision history for this message
David Hess (dhess-8) wrote :
Download full text (8.3 KiB)

Here's an interesting data point. If I run this under valgrind:

$ valgrind openssl s_client -showcerts -connect graph.facebook.com:443
==36982== Memcheck, a memory error detector
==36982== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==36982== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==36982== Command: openssl s_client -showcerts -connect graph.facebook.com:443
==36982==
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = Menlo Park, O = "Facebook, Inc.", CN = *.facebook.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Menlo Park, O = "Facebook, Inc.", CN = *.facebook.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
-----BEGIN CERTIFICATE-----
MIIGkTCCBXmgAwIBAgIQCivCRFoplTX8XaBRF4f4wDANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0yMTEwMDMwMDAwMDBaFw0yMjAxMDEyMzU5NTla
MGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRMwEQYDVQQHEwpN
ZW5sbyBQYXJrMRcwFQYDVQQKEw5GYWNlYm9vaywgSW5jLjEXMBUGA1UEAwwOKi5m
YWNlYm9vay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ9cpj/+XqZgH6d
qstfu/ZUoA+jNBS8A2pE9naG2+/1fDQbFhAK/4N1wNQ69xh2o1KbUId1Qi9sDCWk
Fu6s9XAqo4ID9zCCA/MwHwYDVR0jBBgwFoAUUWj/kK8CB3U8zNllZGKiErhZcjsw
HQYDVR0OBBYEFLARiFqEkLy4TD1U7suyuVQuqD6/MIG1BgNVHREEga0wgaqCDiou
ZmFjZWJvb2suY29tgg4qLmZhY2Vib29rLm5ldIILKi5mYmNkbi5uZXSCCyouZmJz
YnguY29tghAqLm0uZmFjZWJvb2suY29tgg8qLm1lc3Nlbmdlci5jb22CDioueHgu
ZmJjZG4ubmV0gg4qLnh5LmZiY2RuLm5ldIIOKi54ei5mYmNkbi5uZXSCDGZhY2Vi
b29rLmNvbYINbWVzc2VuZ2VyLmNvbTAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9j
cmwzLmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNi5jcmwwNKAyoDCGLmh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNi5jcmwwPgYD
VR0gBDcwNTAzBgZngQwBAgIwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3dy5kaWdp
Y2VydC5jb20vQ1BTMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAGGGGh0dHA6
Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMu
ZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5j
cnQwDAYDVR0TAQH/BAIwADCCAX0GCisGAQQB1nkCBAIEggFtBIIBaQFnAHYAKXm+
8J45OSHwVnOfY6V35b5XfZxgCvj5TV0mXCVdx4QAAAF8Q4ALtQAABAMARzBFAiAB
3r54JbfoFtjAqiLdaY6fXb/o1jjaT9u4XCdN5xu7NAIhAKGf3c1Jzs2cXQcAu422
KlF9P2lXrpZyMmP4rJYTuev2AHYAUaOw9f0BeZxWbbg3eI8MpHrMGyfL956IQpoN
/tSLBeUAAAF8Q4AL8AAABAMARzBFAiEAq7yuxzQO7e+txL6xITlC/qIHDYvapOTh
Tl4NHC+rOj0CIFHm8wXHI/F0gsWQVv5Ot8Ij4RuEZEVMMau/AEMroZ2aAHUAQcjK
sd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF8Q4ALyAAABAMARjBEAiAB
b4Q1lYSN7rcuXUxkIzbum5dVe0caAHuVTYgU00HYkQIgFtebuk3zr+NVZ520RCGZ
fetkFZv08wHf7TJK+JBMnBwwDQYJKoZIhvcNAQELBQADggEBAIcfi8CHi/+QH4cW
BjjDEZnQtPaOG77WtdFW2UK3xt2GKk4qY5rfVKLFGT9vAZRx4ZHFfK6c1IADkNMe
42lwc0+gTBrqrx1Uu+11vAIektX3Lx5xfeCTY604NK1qCC6ISYB/U2NVy2l0skT/
1xKLH87I+P7IwgQtE2en7yt9bu03GPIU0DVkYzqvBxGCq599ae2gYIVZVRSe2Xhp
WVeBB03fhf+NNcbR4LZK7n1ohrUBs7rurc0z6iv8V...

Read more...

Revision history for this message
David Hess (dhess-8) wrote :

More info about my environment:

Running under Parallels 17.1.1 (51537) on macOS Monterey 12.1 on an Apple Silicon M1 Max. Ubuntu Ubuntu 20.04.3 LTS w/ libssl1.1:arm64 1.1.1f-1ubuntu2.10.

Revision history for this message
David Hess (dhess-8) wrote (last edit ):

After a lot of sleuthing with gdb, I'm pretty confident this is the source of (and fix for) the crash we are seeing with libssl1.1:arm64 1.1.1f-1ubuntu2.10:

https://github.com/openssl/openssl/commit/fcf6e9d056162d5af64c6f7209388a5c3be2ce57

It's a bug fix for some pointer authentication assembly instructions for the Poly1305 arm64 assembly code. These instructions only execute (and crash) on Arm v8.3 64 bit processors - they NOOP on other processors that don't understand them.

Note, I have no idea why that code would not also be a problem and crash under valgrind, but I've definitely narrowed this particular crash outside of valgrind down to that location. Maybe valigrind disables pointer authentication....?

It appears the commit above was landed in OpenSSL 1.1.1i:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/crypto/poly1305/asm/poly1305-armv8.pl

Bottom line, in order to prevent crashes on Arm v8.3 processors I believe addressing this requires an upgrade of libssl1.1 to OpenSSL 1.1.1i or patching with that commit.

Revision history for this message
David Hess (dhess-8) wrote :
Download full text (5.3 KiB)

To reproduce, be on an Arm v8.3 processor and do the following:

$ gdb $(which openssl)
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/openssl...
Reading symbols from /usr/lib/debug/.build-id/8c/c0ad363ae4508d48a68d9f9dafdbadf7bd264a.debug...
(gdb) break main
Breakpoint 1 at 0x32840: file ../apps/openssl.c, line 120.
(gdb) run s_client -showcerts -connect graph.facebook.com:443
Starting program: /usr/bin/openssl s_client -showcerts -connect graph.facebook.com:443
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=5, argv=0xfffffffff478) at ../apps/openssl.c:120
120 ../apps/openssl.c: No such file or directory.
(gdb) break ../crypto/poly1305/poly1305.c:502
Breakpoint 2 at 0xfffff7e082c8: file ../crypto/poly1305/poly1305.c, line 502.
(gdb) c
Continuing.
CONNECTED(00000003)

Breakpoint 2, Poly1305_Update (ctx=ctx@entry=0xaaaaaaba97f0, inp=<optimized out>, inp@entry=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>, len=992, len@entry=1001)
    at ../crypto/poly1305/poly1305.c:502
502 ../crypto/poly1305/poly1305.c: No such file or directory.
(gdb) s
poly1305_blocks_neon () at crypto/poly1305/poly1305-armv8.S:223
223 crypto/poly1305/poly1305-armv8.S: No such file or directory.
(gdb) bt
#0 poly1305_blocks_neon () at crypto/poly1305/poly1305-armv8.S:223
#1 0x0000fffff7e082dc in Poly1305_Update (ctx=ctx@entry=0xaaaaaaba97f0, inp=<optimized out>, inp@entry=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>,
    len=<optimized out>, len@entry=1001) at ../crypto/poly1305/poly1305.c:502
#2 0x0000fffff7dd7834 in chacha20_poly1305_cipher (ctx=0xaaaaaaba95b0, out=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>,
    in=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>, len=1001) at ../crypto/evp/e_chacha20_poly1305.c:419
#3 0x0000fffff7ddc214 in EVP_DecryptUpdate (inl=1001, in=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>, outl=0xffffffffe360,
    out=0xaaaaaab9e098 "\362Hd\025\245\223\351f\027\265 b䓁\207<s\261\027\036\230\031Y/\031M\307D\"F\370", <incomplete sequence \356>, ctx=...

Read more...

Revision history for this message
David Hess (dhess-8) wrote :

If anybody needs a workaround, disable the CHACHA20 cipher suites which use Poly1305:

$ openssl s_client -debug -showcerts -connect graph.facebook.com:443 -ciphersuites TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 -cipher 'ALL:!CHACHA20'

Unfortunately, it appears this can't be done system wide from /etc/ssl/openssl.conf - it needs to be done in a tool specific way for each tool using openssl (such as curl: https://curl.se/docs/ssl-ciphers.html).

Revision history for this message
Anders Kaseorg (andersk) wrote :

David Hess’s analysis is correct. This is a bug in the ARM64 assembly for Poly1305, introduced in

https://github.com/openssl/openssl/commit/2cf7fd698ec1375421f91338ff8a44e7da5238b6 (OpenSSL_1_1_1b~37)

and fixed upstream in

https://github.com/openssl/openssl/commit/5795acffd8706e1cb584284ee5bb3a30986d0e75 (OpenSSL_1_1_1i~21).

This fix needs to be backported to focal.

Changed in openssl (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Anders Kaseorg (andersk) wrote :

Here’s a debdiff with the two-line upstream fix.

tags: added: focal patch patch-accepted-upstream regression-release
Changed in openssl:
status: Unknown → Fix Released
Changed in openssl (Debian):
status: Unknown → New
Mathew Hodson (mhodson)
Changed in openssl (Ubuntu):
status: Confirmed → Fix Released
importance: Undecided → Medium
Changed in openssl (Ubuntu Focal):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssl (Ubuntu Focal):
status: New → Confirmed
Changed in openssl (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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