[gnutls-devel] GnuTLS | crypto-api: always allocate memory when serializing iovec_t (!1278)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Fri Jun 5 18:35:12 CEST 2020



Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1278

Branches: tmp-iov-memleak to master
Author:    Daiki Ueno



The AEAD iov interface falls back to serializing the input buffers if
the low-level cipher doesn't support scatter/gather encryption.
However, there was a bug in the functions used for the serialization,
which causes memory leaks under a certain condition (i.e. the number
of input buffers is 1).

This patch makes the logic of the functions simpler, by removing a
micro-optimization that tries to minimize the number of calls to
malloc/free.

The original problem was reported by Marius Steffen in:
https://bugzilla.samba.org/show_bug.cgi?id=14399
and the cause was investigated by Alexander Haase in:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1277

Fixes #1017.

## Checklist
 * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author
 * [ ] Code modified for feature
 * [x] Test suite updated with functionality tests
 * [x] Test suite updated with negative tests
 * [ ] Documentation updated / NEWS entry present (for non-trivial changes)
 * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout)

## Reviewer's checklist:
 * [ ] Any issues marked for closing are addressed
 * [ ] There is a test suite reasonably covering new functionality or modifications
 * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md`
 * [ ] This feature/change has adequate documentation added
 * [ ] No obvious mistakes in the code

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1278
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200605/d112edb1/attachment-0001.html>


More information about the Gnutls-devel mailing list