security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-07-02 22:46:30 +02:00
Code Activity

common/iobuf.c: Buffered data should not be processed by new filters.

Browse source 
* common/iobuf.c (iobuf_push_filter2): If the pipeline is an output or
temp pipeline, the new filter shouldn't assume ownership of the old
head's internal buffer: the data was written before the filter was
added.
* common/t-iobuf.c (double_filter): New function.
(main): Add test cases for the above bug.

--
Signed-off-by: Neal H. Walfield <neal@g10code.com>.
This commit is contained in:
Neal H. Walfield 2015-08-17 11:56:42 +02:00
parent 616181f3c7
commit 827cc922d8
2 changed files with 116 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

29
common/iobuf.c
View file

@ -1607,20 +1607,21 @@ iobuf_push_filter2 (iobuf_t a,
/* make a write stream from a temp stream */
a->use = IOBUF_OUTPUT;
if (a->use == IOBUF_OUTPUT)
{ /* allocate a fresh buffer for the
original stream */
b->d.buf = xmalloc (a->d.size);
b->d.len = 0;
b->d.start = 0;
}
else
{ /* allocate a fresh buffer for the new
stream */
a->d.buf = xmalloc (a->d.size);
a->d.len = 0;
a->d.start = 0;
}
/* The new filter (A) gets a new buffer.
If the pipeline is an output or temp pipeline, then giving the
buffer to the new filter means that data that was written before
the filter was pushed gets sent to the filter. That's clearly
wrong.
If the pipeline is an input pipeline, then giving the buffer to
the new filter (A) means that data that has read from (B), but
not yet read from the pipeline won't be processed by the new
filter (A)! That's certainly not what we want. */
a->d.buf = xmalloc (a->d.size);
a->d.len = 0;
a->d.start = 0;
/* disable nlimit for the new stream */
a->ntotal = b->ntotal + b->nbytes;
a->nlimit = a->nbytes = 0;