diff options
| author | Tobias Stoeckmann <tobias@stoeckmann.org> | 2024-01-04 18:30:28 +0100 |
|---|---|---|
| committer | Dmitry V. Levin <ldv@strace.io> | 2024-01-05 23:36:44 +0000 |
| commit | b6faf3c6cbf2f27a1976e462e2ea6fa09f1aad3d (patch) | |
| tree | 84d21d1944bdb4ea68e1c31a8942e99870676ee7 /modules/pam_unix/pam_unix_passwd.c | |
| parent | 14ad78c43158291f179a6e77c8695964659f2ed5 (diff) | |
| download | pam-b6faf3c6cbf2f27a1976e462e2ea6fa09f1aad3d.tar.gz pam-b6faf3c6cbf2f27a1976e462e2ea6fa09f1aad3d.tar.bz2 pam-b6faf3c6cbf2f27a1976e462e2ea6fa09f1aad3d.zip | |
libpam: handle long delays properly
If a delay close to UINT_MAX has been set, then the delay computation
might overflow the value due to added randomness.
Systems where linux-pam is in use should generally have a 32 bit
unsigned int and a 64 bit unsigned long long, and a time_t of either
64 bit or 32 bit. Under these assumptions, using the result for delay is
safe because of the division before assigning it to tv_sec (time_t).
Thought about using uint64_t type here but as long as "unsigned int"
is part of the API instead of uint32_t, no proper guarantees could be
made anyway.
Unfortunately we have to supply an unsigned int if a PAM_FAIL_DELAY
function has been set. In such a case, supply a UINT_MAX if delay is
larger than that. It's the best we can do without breaking the API.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Diffstat (limited to 'modules/pam_unix/pam_unix_passwd.c')
0 files changed, 0 insertions, 0 deletions