[OE-core] [meta-oe][sumo][PATCH] strongswan: avoid charon crash
Saloni Jain
Saloni.Jain at kpit.com
Thu Feb 20 10:58:35 UTC 2020
From: Anuj Chougule <Anuj.Chougule at kpit.com>
This is a possible fix to charon that crashed early due to invalid
memory access.
Important frames from Backtraces :
8 0x00007f607246e160 in memcpy (__len=1704, __src=<optimized out>, __dest=<optimized out>)
at /usr/include/bits/string_fortified.h:34
No locals.
9 memcpy_noop (n=1704, src=<optimized out>, dst=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/utils/memory.h:47
n = 1704
src = <optimized out>
dst = <optimized out>
10 chunk_create_clone (ptr=<optimized out>, chunk=...)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/chunk.c:48
clone = <optimized out>
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type at entry=CRED_PRIVATE_KEY, subtype=subtype at entry=1,
subject=subject at entry=0x0, flags=flags at entry=X509_NONE)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
x = <optimized out>
cred = 0x0
---Type <return> to continue, or q <return> to quit---
pgp = false
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
cred = <optimized out>
chunk = 0x7f6054005430
13 pem_load (type=CRED_PRIVATE_KEY, subtype=1, args=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:498
file = 0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem"
pem = <optimized out>
subject = 0x0
flags = 0
Problem lies in frame 12 & 11.
(gdb) f 12
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
452 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info locals
cred = <optimized out>
chunk = 0x7f6054005430
(gdb) print *chunk
$21 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 1704}
(gdb) f 11
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type at entry=CRED_PRIVATE_KEY, subtype=subtype at entry=1, subject=subject at entry=0x0,
flags=flags at entry=X509_NONE) at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
399 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info args
blob = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
type = CRED_PRIVATE_KEY
subtype = 1
subject = 0x0
flags = X509_NONE
(gdb) print blob
$22 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
Source code snippet :
static void *load_from_file(char *file, credential_type_t type, int subtype,
identification_t *subject, x509_flag_t flags)
{
void *cred;
chunk_t *chunk;
chunk = chunk_map(file, FALSE);
if (!chunk)
{
DBG1(DBG_LIB, " opening '%s' failed: %s", file, strerror(errno));
return NULL;
}
cred = load_from_blob(*chunk, type, subtype, subject, flags);
chunk_unmap(chunk);
return cred;
}
Local variable chunk is an uninitialised pointer in load_from_file()
(frame 12 above) which is expected to get initialised through
chunk_map() & then passed to load_from_blob() as a parameter.
But somehow, the chunk pointer has not got initialised &
got passed as it is to load_from_blob() in frame 11 above.
As this contains a garbage address, when method load_from_blob()
tried cloning the memory regions through chunk_clone() ->
chunk_create_clone() -> memcpy() -> memcpy_noop(), it crashed with
SIGBUS (frames 10, 9, 8).
It could also be that chunk_map() has a bug which does not memmap()
the full or correct areas.
Upstream-Status: Pending
Tested By: Anuj Chougule <Anuj.Chougule at kpit.com>
Signed-off-by: Anuj Chougule <Anuj.Chougule at kpit.com>
Signed-off-by: Saloni Jain <Saloni.Jain at kpit.com>
---
.../strongswan/files/fix-charon-crash.patch | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 recipes-support/strongswan/files/fix-charon-crash.patch
diff --git a/recipes-support/strongswan/files/fix-charon-crash.patch b/recipes-support/strongswan/files/fix-charon-crash.patch
new file mode 100644
index 0000000..95e71a2
--- /dev/null
+++ b/recipes-support/strongswan/files/fix-charon-crash.patch
@@ -0,0 +1,23 @@
+strongswan: avoid charon crash
+
+Variable chunk is an uninitialised pointer,which
+is expected to get initialised through method chunk_map()
+& then passed to load_from_blob() as a parameter.
+But somehow, if the chunk pointer did not get initialised & gets
+passed as it is to load_from_blob(), it may lead crash as this
+contains a garbage address.
+
+Signed-off-by: Anuj Chougule <Anuj.Chougule at kpit.com>
+Upstream-Status: Pending
+
+--- a/src/libstrongswan/plugins/pem/pem_builder.c
++++ b/src/libstrongswan/plugins/pem/pem_builder.c
+@@ -441,7 +441,7 @@ static void *load_from_file(char *file, credential_type_t type, int subtype,
+ identification_t *subject, x509_flag_t flags)
+ {
+ void *cred;
+- chunk_t *chunk;
++ chunk_t *chunk = NULL;
+
+ chunk = chunk_map(file, FALSE);
+ if (!chunk)
--
2.7.4
This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200220/6ccad9bf/attachment-0001.html>
More information about the Openembedded-core
mailing list