summaryrefslogtreecommitdiff
path: root/crypto/xcbc.c
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2012-10-02 17:36:16 +0400
committerRusty Russell <rusty@rustcorp.com.au>2012-10-10 13:36:37 +0400
commita5752d11b3853fcdb48b303573dd39b09d05e500 (patch)
treefdbf54986ce97f473661d62510a513bb4ba79aa9 /crypto/xcbc.c
parentd5b719365ec13ef825f2548ba54903b9d029238c (diff)
downloadlinux-a5752d11b3853fcdb48b303573dd39b09d05e500.tar.xz
MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking
The current choice of lifetime for the autogenerated X.509 of 100 years, putting the validTo date in 2112, causes problems on 32-bit systems where a 32-bit time_t wraps in 2106. 64-bit x86_64 systems seem to be unaffected. This can result in something like: Loading module verification certificates X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired MODSIGN: Problem loading in-kernel X.509 certificate (-127) Or: X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 is not yet valid MODSIGN: Problem loading in-kernel X.509 certificate (-129) Instead of turning the dates into time_t values and comparing, turn the system clock and the ASN.1 dates into tm structs and compare those piecemeal instead. Reported-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'crypto/xcbc.c')
0 files changed, 0 insertions, 0 deletions