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>
The ssh_channel_is_closed function would crash when
accessing channel->session->alive if session is NULL.
This patch adds a null check before accessing the session
pointer.
- build succeeded
- unit test passed
- no new unit test added
https://gitlab.com/libssh/libssh-mirror/-/issues/239
Signed-off-by: Raviraaja Lakshmanan <mailstoraviraaja@gmail.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This was omitted from the 84d02e74 and caused issues to build when abimap is
not present.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This could happen only if the function would really be called with the NULL
session, but this was never the case as the session is dereferenced already on
all code paths toward this place.
This is just to make the scanner happy that the session can not really be NULL
here.
Thanks coverity!
CID 1593926
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <norbertpocs0@gmail.com>
