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

 
 

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

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

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

Fixed in git, feacacc.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 30 Jul 2016 09:06:12 AM UTCbensOpen/ClosedOpen=>Closed
    Wed 29 Jun 2016 07:00:41 PM UTCbensStatusIn Progress=>Fixed
    Sat 04 Jun 2016 08:00:21 PM UTCbensStatusNone=>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.1-cleanup1