This is mostly mechanical change initializing all the pointers I was able to
find with some grep and manual review of sources and examples.
Used the following greps (which yield some false positives though):
git grep " \w* *\* *\w*;$"
git grep " ssh_session \w*;"
git grep " ssh_channel \w*;"
git grep " struct ssh_iterator \*\w*;"
git grep " ssh_bind \w*;"
git grep " ssh_key \w*;"
git grep " ssh_string \w*;"
git grep " ssh_buffer \w*;"
git grep " HMACCTX \w*;"
git grep " SHACTX \w*;"
grep -rinP '^(?!.*=)\s*(?:\w+\s+)*\w+\s*\*\s*\w+\s*;'
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
On 32b architecture when processing the SFTP packets, the value
0x7ffffffc in the payload_len will overflow to negative integer values,
causing these checks to pass and possibly reading behind the buffer
bounds later.
This affects only SFTP server implementations running on 32b
architecture.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Set maximum input to 256MB to have safe margin to the 1GB trigger point
for 32b arch.
The OOB should not be reachable by any internal code paths as most of
the buffers and strings we use as input for this operation already have
similar limit and none really allows this much of data.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The spread out initialization and variable definition (and alising)
was hell to keep up with and was causing memory issues as reported by valgrind:
==4480== 128 bytes in 1 blocks are definitely lost in loss record 1 of 12
==4480== at 0x48463F3: calloc (vg_replace_malloc.c:1675)
==4480== by 0x487D152: mbedtls_mpi_grow (bignum.c:218)
==4480== by 0x487D6C5: mbedtls_mpi_copy (bignum.c:334)
==4480== by 0x48B9627: mbedtls_rsa_export (rsa.c:899)
==4480== by 0x283955: pki_key_to_blob (pki_mbedcrypto.c:976)
==4480== by 0x24F162: ssh_pki_export_privkey_blob (pki.c:2188)
==4480== by 0x278001: ssh_pki_openssh_privkey_export (pki_container_openssh.c:546)
==4480== by 0x24D7D2: ssh_pki_export_privkey_file_format (pki.c:1122)
==4480== by 0x24D916: torture_pki_rsa_write_privkey_format (torture_pki_rsa.c:895)
==4480== by 0x24D916: torture_pki_rsa_write_privkey (torture_pki_rsa.c:962)
==4480== by 0x4865499: ??? (in /usr/lib64/libcmocka.so.0.8.0)
==4480== by 0x4865C0B: _cmocka_run_group_tests (in /usr/lib64/libcmocka.so.0.8.0)
==4480== by 0x252115: torture_run_tests (torture_pki_rsa.c:1160)
==4480== by 0x2546B8: main (torture.c:1984)
==4480==
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Eshan Kelkar <eshankelkar@galorithm.com>
Originally reported by Till on mailing list here:
https://archive.libssh.org/libssh/2025-05/0000000.html
After some debugging, it turns out the client code does not guarantee
the extensions are processed before making decisions on the signature algorithm
that is being used for authentication, causing false-positive failures.
This does not happen in the tests, where we initially call ssh_userauth_none,
which enumerates authentications methods and as a side effect processes
outstanding packets such as SSH_EXT_INFO message with the server-sig-algs
extension.
When the first function called after `ssh_connect()` is
`ssh_userauth_publickey()`, the `ssh_userauth_request_service()` was wrongly
called only after the signature algorithm compatibility was checked.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <norbertpocs0@gmail.com>
