bugGNU Screen - Bugs: bug #58259, Memory corruption by terminfo

 
 

bug #58259: Memory corruption by terminfo

Submitter:  Victor Dmitriev <mrwitek>
Submitted:  Mon 27 Apr 2020 03:14:12 PM UTC
   
 
Category:  Crash/Freeze/Infloop Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Ready For Test
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  4.8.0
Fixed Release:  None Planned Release:  4.9.1
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 21 Feb 2022 06:03:55 PM UTC, comment #4: 

Scott, thanks a lot!

Victor, can you test this patch?

Alexander Naumov <anaumov>
Group administrator
Mon 21 Feb 2022 05:45:56 AM UTC, comment #3: 

I've attached a patch that calculates the space needed by the terminfo string items before loading them.  Large terminfo structs should no longer corrupt memory.


(file #52897)

Scott Shambarger <sshambar>
Sat 12 Feb 2022 04:22:16 AM UTC, comment #2: 

Finally had a chance to take a look at this one... found the source of the problem:

termcap.c:156
        case T_STR:
          D_tcs[i].str = e_tgetstr(term[i].tcname, &tp);

tgetstr(), the tp buffer is expected to have 1024, but tp is advanced on return... and there's no check on overflow when called repeatedly.  If the source is termcap, a 1024 buffer is fine as that's the standard termcap size limit anyway... with a terminfo source, the limit is really T_STR(1024) * T_N entries... unlikely, but quite legal.

There's a function called t_agetstr which handles (re)allocation of the buffer, but may not be available on all platforms.

A portable solution would be to pass NULL as tp and then copy the return value to a realloc'd buffer locally sized to handle the value.

Using TERMCAP_BUFSIZE for tp is really not correct here (regardless of value).  I could supply a patch to handle a realloc buffer solution, unless someone has a better solution?

Scott Shambarger <sshambar>
Fri 04 Feb 2022 06:26:28 PM UTC, comment #1: 

Victor, thank for report.

Yes, entries larger than TERMCAP_BUF are truncated since 4.8.0 and this is 1023 (before it was 2048).
It seems we need some "compromise fix" here...

Alexander Naumov <anaumov>
Group administrator
Mon 27 Apr 2020 03:14:12 PM UTC, original submission:  

In version 4.8.0 screen can corrupt memory when reading terminfo/termcap files.

I use st terminal with environment variable TERM=st-256color. If I have compiled st.info (with warnings) from the source with

tic -o "$HOME/.terminfo" st.info

trying to start screen results in one process becoming a zombie and another process blocking terminal until I press Ctrl+\.

If I have compiled st.info as recommended in st FAQ with

tic -o "$HOME/.terminfo" -x st.info

trying to reattach to screen session results in an infinite loop in _nc_find_type_entry in libncursesw.so.6 (bug #58132)

The problem is not present in version 4.7.0.
Workaround: add " -DTERMCAP_BUFSIZE=2048" to CPPFLAGS environment variable and reconfigure/rebuild. In that case problem is no longer present.

P.S. bugtracker misses 4.8.0 entry in the release field.

Victor Dmitriev <mrwitek>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sshambar (Posted a comment)
  • -email is unavailable- added by anaumov (Updated the item)
  • -email is unavailable- added by mrwitek (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.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-21 anaumov StatusNeed Discussion Ready For Test
        Planned ReleaseNone 4.9.1
    2022-02-21 sshambar Attached File- Added 0001-Fix-memory-corruption-when-loading-large-terminfos.patch, #52897
    2022-02-04 anaumov StatusNone Need Discussion
    2020-04-27 anaumov Release4.99.0 4.8.0

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code