Re: heap-buffer-overflow in history_expand

[Chet Ramey]

On 4/30/23 5:03 AM, Grisha Levit wrote:
> On Sat, Apr 29, 2023, 14:02 Chet Ramey <chet.ramey@case.edu 
> <mailto:chet.ramey@case.edu>> wrote:
>
>     On 4/28/23 9:28 PM, Grisha Levit wrote:
>      > Piping input that simply ends in an leading byte doesn't trigger the
>     issue
>      > -- that byte byte don't seem to make it into the input line.
>      >
>      > This is a bit off topic, but I don't really understand what happens
>     with
>      > invalid input sequences in the input, see e.g.:
>
>     They should be treated as individual bytes.
>
>
> I think I see what's happening now. Readline accumulates the bytes until a 
> complete character is read. However, this buffer is not flushed when the 
> reading of a multibyte character is interrupted by inserting a single byte 
> character, or by any non-insertion command.

Yes, I concluded the same thing. Thanks for the patch. I have one question
about the change to rl_insert: why overwrite any return value from the
initial call to _rl_insert_char by setting r back to 0? What if the initial
value of C starts an incomplete multibyte character, and is then followed
by a character that doesn't contribute?

I also haven't decided what to do if we get a character that is part of
an accumulating multibyte character that is mapped to an editing command.
That is, fortunately, rare.

(And once we get these issues straightened out, if you look back to your
original example, 0x240 is a blank in my locale, en_US.UTF-8, and will be
removed from the input stream by the parser unless it's quoted.)

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/