This bug was fixed in the package openssl - 1.0.2g-1ubuntu14
---
openssl (1.0.2g-1ubuntu14) bionic; urgency=medium
* SECURITY UPDATE: Malformed X.509 IPAddressFamily could cause OOB read
- debian/patches/CVE-2017-3735.patch: avoid out-of-bounds read in
crypto/x509v3/v3_add
This bug was fixed in the package openssl - 1.0.2g-1ubuntu13.2
---
openssl (1.0.2g-1ubuntu13.2) artful-security; urgency=medium
* SECURITY UPDATE: Malformed X.509 IPAddressFamily could cause OOB read
- debian/patches/CVE-2017-3735.patch: avoid out-of-bounds read in
crypto/
This is a deliberate change in binutils-2.29, which changes how the ADR
instruction works with Thumb function symbols:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;a=commit;h=52a86f843b6dee1de9977293da9786649b146b05
There are some changes in openssl which work around this:
https://g
** Changed in: gcc-7 (Ubuntu)
Status: New => Invalid
** Changed in: binutils (Ubuntu)
Status: New => Invalid
** Also affects: binutils (Ubuntu Bionic)
Importance: Undecided
Status: Invalid
** Also affects: openssl (Ubuntu Bionic)
Importance: Undecided
Status: Ne
I also verified that with this workaround for the first instruction, the
non-NEON path passes the test, by removing this block from
sha256-armv4.S:
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
ldr r12,[r3,r12]@ OPENSSL_armcap_P
I stepped through 2 builds side-by-side in gdb - one good build built
with gcc 7.1, and one bad build, built with gcc 7.2. I managed to narrow
it down to a bug in sha256_block_data_order.
One of the first differences I spotted was that the good build branches
almost immediately to a NEON code path
Continuing debugging the broken build, if we look at the first few
instructions of sha256_block_data_order:
0x004160c0 <+0>: subwr3, pc, #3
0x004160c4 <+4>: ldr.w r12, [pc, #-36] ; 0x4160a4
0x004160c8 <+8>: ldr.w r12, [r3, r12]
This looks similar to before - the inten
The incorrect instruction at the start of sha256_block_data_order comes
from the ADR pseudo-instruction in sha256-armv4.S:
.global sha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8@ sha256_block_da
On the broken build, the first thing to notice is that when entering
sha256_block_data_order, we are running in Thumb mode, as bit 5 of the
status register is set:
(gdb) info registers
r0 0x4b7558 4945240
r1 0x4b7580 4945
Changing the start of sha256_block_data_order in sha256-armv4.S to avoid
the use of the ADR pseudo-instruction like this:
global sha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
#ifdef __thumb2__
sub r3,pc,#4@ sha256_block_data_
It FTBFS with gcc 7.2 in artful and bionic, but builds fine with gcc 7.1
that was previously in artful.
Openssl 1.0.2m fails in the same way.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.lau
11 matches
Mail list logo