nscd: Use time_t for return type of addgetnetgrentX
Checks
| Context |
Check |
Description |
| redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
| linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
warning
|
Patch is already merged
|
| linaro-tcwg-bot/tcwg_glibc_build--master-arm |
warning
|
Patch is already merged
|
Commit Message
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
Comments
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
@@ -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;