bugGNU nano - Bugs: bug #48125, the representation of invalid...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #48125: the representation of invalid multibyte sequences depends on uninitialized data

Submitter:  Benno Schulenberg <bens>
Submitted:  Sat 04 Jun 2016 12:19:26 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Wed 29 Jun 2016 07:00:41 PM UTC, comment #4: 

Fixed in git, feacacc.

Benno Schulenberg <bens>
Group administrator
Sun 05 Jun 2016 07:59:56 AM UTC, comment #3: 

The command should of course have been:

xxd -r <<<"0000: c220 2020 c220 2020 c234 2020 c255" >hex

Don't know why Savannah ate the ex.

Benno Schulenberg <bens>
Group administrator
Sat 04 Jun 2016 08:00:21 PM UTC, comment #2: 

When 'buf_mb_len = parse_mbchar(buf + start_index, buf_mb, NULL)' tries to parse an invalid multibyte sequence, it does not return the Replacement Character but the /unterminated/ first byte.  The three other bytes in the allocated buffer will contain random data.  If the first byte together with the random second byte happens to form a valid control sequence, nano will mistakenly classify it as a control and show it as such.

This parsing first of each character into a separate little buffer is actually making things harder (and wasting time): just look at the bytes in their context.  The latter is always possible: it will never overshoot the end of the string, because a terminating zero will cut everything short: a 0x00 is never part of any valid UTF-8 code (except as itself).

Benno Schulenberg <bens>
Group administrator
Sat 04 Jun 2016 12:34:58 PM UTC, comment #1: 

To reproduce, run:

xxd -r <<<"0000: c220 2020 c220 2020 c234 2020 c255" >h

The output of 'MALLOC_PERTURB_=32 src/nano hex' will look like it should:
�   �   �4  �U

But the output of 'MALLOC_PERTURB_=104 src/nano hex' looks like this:

^×   ^×   ^×4  �U

Bug is old, since at least nano-2.2.1.

Benno Schulenberg <bens>
Group administrator
Sat 04 Jun 2016 12:19:26 PM UTC, original submission:  

The representation of one and the same file can differ when run in different terminals (which here will randomly have different values of MALLOC_PERTURB_).  It seems to happen only for invalid multibyte sequences.

For the one example I found, valgrind says this:

==11189== Conditional jump or move depends on uninitialised value(s)
==11189==    at 0x40A3811: __gconv_transform_utf8_internal (loop.c:332)
==11189==    by 0x4108862: mbrtowc (mbrtowc.c:82)
==11189==    by 0x40C59DC: mbtowc (mbtowc.c:65)
==11189==    by 0x804BF8D: is_cntrl_mbchar (chars.c:178)
==11189==    by 0x8062DF4: display_string (winio.c:1869)
==11189==    by 0x8062FCE: update_line (winio.c:2707)
==11189==    by 0x8063185: edit_refresh (winio.c:2971)
==11189==    by 0x80588AA: main (nano.c:2656)
==11189==  Uninitialised value was created by a heap allocation
==11189==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==11189==    by 0x806162B: nmalloc (utils.c:389)
==11189==    by 0x8062BB4: display_string (winio.c:1761)
==11189==    by 0x8062FCE: update_line (winio.c:2707)
==11189==    by 0x8063185: edit_refresh (winio.c:2971)
==11189==    by 0x80588AA: main (nano.c:2656)

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-30 bens Open/ClosedOpen Closed
    2016-06-29 bens StatusIn Progress Fixed
    2016-06-04 bens StatusNone In Progress
        Summarysomething in the representation of multibyte characters depends on unitialized data the representation of invalid multibyte sequences depends on uninitialized data

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code