| Message ID | 87edakl07j.fsf@oldenburg.str.redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | nscd: Use time_t for return type of addgetnetgrentX | expand |
On 5/2/24 11:09, Florian Weimer wrote: > Using int may give false results for future dates (timeouts after the > year 2028). > > Fixes commit 04a21e050d64a1193a6daab872bca2528bda44b ("CVE-2024-33601, > CVE-2024-33602: nscd: netgroup: Use two buffers in addgetnetgrentX > (bug 31680)"). Yes, this is a Y2038 issue where the 64-bit time_t is truncated to 32-bits. The NSS service may indeed set timeout to *any* time in the future so it could impact today, but in the netgroupcache.c code today we take the postimeout and negtimeout from the database which is either 28800 or 20 respectively. The other scenario is a VM set to the future which would run into this immediately. Would be nice to try that at some time e.g. run the testsuite in a VM with time set to 2039? Reviewed-by: Carlos O'Donell <carlos@redhat.com> > --- > nscd/netgroupcache.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/nscd/netgroupcache.c b/nscd/netgroupcache.c > index 4b35498e3f..5fdcf4204e 100644 > --- a/nscd/netgroupcache.c > +++ b/nscd/netgroupcache.c > @@ -680,8 +680,8 @@ readdinnetgr (struct database_dyn *db, struct hashentry *he, > .key_len = he->len > }; > > - int timeout = addinnetgrX (db, -1, &req, db->data + he->key, he->owner, > - he, dh); > + time_t timeout = addinnetgrX (db, -1, &req, db->data + he->key, he->owner, > + he, dh); > if (timeout < 0) > timeout = 0; > return timeout; > > base-commit: 552073e4b88183994d8e13f693317bad89dd40f7 >
* Carlos O'Donell: > On 5/2/24 11:09, Florian Weimer wrote: >> Using int may give false results for future dates (timeouts after the >> year 2028). >> >> Fixes commit 04a21e050d64a1193a6daab872bca2528bda44b ("CVE-2024-33601, >> CVE-2024-33602: nscd: netgroup: Use two buffers in addgetnetgrentX >> (bug 31680)"). > > Yes, this is a Y2038 issue where the 64-bit time_t is truncated to 32-bits. > > The NSS service may indeed set timeout to *any* time in the future so it could > impact today, but in the netgroupcache.c code today we take the postimeout and > negtimeout from the database which is either 28800 or 20 respectively. > > The other scenario is a VM set to the future which would run into this > immediately. Would be nice to try that at some time e.g. run the > testsuite in a VM with time set to 2039? It's on the re-add path only, so I don't think it's *that* easy to test. > Reviewed-by: Carlos O'Donell <carlos@redhat.com> Thanks. Florian
diff --git a/nscd/netgroupcache.c b/nscd/netgroupcache.c index 4b35498e3f..5fdcf4204e 100644 --- a/nscd/netgroupcache.c +++ b/nscd/netgroupcache.c @@ -680,8 +680,8 @@ readdinnetgr (struct database_dyn *db, struct hashentry *he, .key_len = he->len }; - int timeout = addinnetgrX (db, -1, &req, db->data + he->key, he->owner, - he, dh); + time_t timeout = addinnetgrX (db, -1, &req, db->data + he->key, he->owner, + he, dh); if (timeout < 0) timeout = 0; return timeout;
Using int may give false results for future dates (timeouts after the year 2028). Fixes commit 04a21e050d64a1193a6daab872bca2528bda44b ("CVE-2024-33601, CVE-2024-33602: nscd: netgroup: Use two buffers in addgetnetgrentX (bug 31680)"). --- nscd/netgroupcache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) base-commit: 552073e4b88183994d8e13f693317bad89dd40f7