grep linux command memory corruption

Credit: Seth Arnold
Risk: Medium
Local: Yes
Remote: No

Ogólna skala CVSS: 4.4/10
Znaczenie: 6.4/10
Łatwość wykorzystania: 3.4/10
Wymagany dostęp: Lokalny
Złożoność ataku: Średnia
Autoryzacja: Nie wymagana
Wpływ na poufność: Częściowy
Wpływ na integralność: Częściowy
Wpływ na dostępność: Częściowy

A bug reporter [1] that claims he has, or can produce, a code execution exploit against grep < 2.11. I've verified that our grep 2.10 package segfaults on the amd64 platform with the simple reproducer: $ perl -e 'print "x"x(2**31)' | grep x > /dev/null Segmentation fault (core dumped) This specific problem was patched [2] with the following checkin: This checkin adds this text to the NEWS file: + grep no longer dumps core on lines whose lengths do not fit in 'int'. + (e.g., lines longer than 2 GiB on a typical 64-bit host). + Instead, grep either works as expected, or reports an error. + An error can occur if not enough main memory is available, or if the + GNU C library's regular expression functions cannot handle such long lines. + [bug present since "the beginning"] Please assign a CVE number for this problem. Several other checkins around the 2.11 timeframe also look like they may be security-relevant: PCRE over-long line fix: Integer overflow issues: Paul, are any security issues fixed with those patches? Did I overlook any other patches that need CVE numbers? Thanks 1: 2:


Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2020,


Back to Top