On Mon, Jan 4, 2016 at 5:17 PM, David Howells <[email protected]> wrote: > The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601 > [X.680 46.3] and this apparently supports leap seconds (ie. the seconds > field is 60). It's not entirely clear that ASN.1 expects it, but we can > relax the seconds check slightly for GeneralizedTime. > > This results in us passing a time with sec as 60 to mktime64(), which > handles it as being a duplicate of the 0th second of the next minute. > > We can't really do otherwise without giving the kernel much greater > knowledge of where all the leap seconds are. Unfortunately, this would > require change the mapping of the kernel's current-time-in-seconds. > > UTCTime, however, only supports a seconds value in the range 00-59, but for > the sake of simplicity allow this with UTCTime also. > > Without this patch, certain X.509 certificates will be rejected, > potentially making a kernel unbootable. > > Reported-by: Rudolf Polzer <[email protected]> > Signed-off-by: David Howells <[email protected]> > cc: Arnd Bergmann <[email protected]> > cc: David Woodhouse <[email protected]> > cc: John Stultz <[email protected]> > --- > > crypto/asymmetric_keys/x509_cert_parser.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c > b/crypto/asymmetric_keys/x509_cert_parser.c > index 13c4e5a5fe8c..3379c0ba3988 100644 > --- a/crypto/asymmetric_keys/x509_cert_parser.c > +++ b/crypto/asymmetric_keys/x509_cert_parser.c > @@ -550,7 +550,7 @@ int x509_decode_time(time64_t *_t, size_t hdrlen, > if (day < 1 || day > mon_len || > hour > 23 || > min > 59 || > - sec > 59) > + sec > 60) /* ISO 8601 permits leap seconds [X.680 46.3] */ > goto invalid_time; > > *_t = mktime64(year, mon, day, hour, min, sec); >
All good. I find it a bit odd that it only allows for _one_ leap second, although there can be technically two in a single minute - but this is the problem of the standard, not of this code. Best regards, Rudolf Polzer
