Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
It was discovered that the nss_files backend for the Name Service Switch in glibc would return incorrect data to applications or corrupt the heap (depending on adjacent heap contents). A local attacker could potentially use this flaw to execute arbitrary code on the system.
DescriptionNalin Dahyabhai
2014-05-19 21:08:38 UTC
Created attachment 897322[details]
Test program, takes optional user name ("root") and initial buffer size (4) as arguments
Description of problem:
In glibc-2.17-c758a686/nss/nss_files/files-XXX.c, in get_contents(), the loop appears to be checking for a too-small passed-in buffer incorrectly, in that it assigns 0xff to the final byte in the buffer after passing the buffer to fgets_unlocked instead of before.
Version-Release number of selected component (if applicable):
glibc-2.17-55.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Call getpwnam_r() with bufsize set to a small number (4 in my test).
Actual results:
getpwnam_r() returns 0
Expected results:
getpwnam_r() returns ERANGE
Comment 3Siddhesh Poyarekar
2015-03-03 13:55:10 UTC
This is not reproducible on F21, so we probably have a patch for this already; it's just a matter of bisecting it. From a quick look, the following commit may have fixed this as a side-effect.
commit 977f4b31b7ca4a4e498c397f3fd70510694bbd86
Author: Siddhesh Poyarekar <siddhesh>
Date: Wed Oct 30 16:13:37 2013 +0530
Fix reads for sizes larger than INT_MAX in AF_INET lookup
Currently for AF_INET lookups from the hosts file, buffer sizes larger
than INT_MAX silently overflow and may result in access beyond bounds
of a buffer. This happens when the number of results in an AF_INET
lookup in /etc/hosts are very large.
There are two aspects to the problem. One problem is that the size
computed from the buffer size is stored into an int, which results in
overflow for large sizes. Additionally, even if this size was
expanded, the function used to read content into the buffer (fgets)
accepts only int sizes. As a result, the fix is to have a function
wrap around fgets that calls it multiple times with int sizes if
necessary.
Comment 6Siddhesh Poyarekar
2015-03-09 07:28:22 UTC
(In reply to Siddhesh Poyarekar from comment #3)
> This is not reproducible on F21, so we probably have a patch for this
> already; it's just a matter of bisecting it. From a quick look, the
> following commit may have fixed this as a side-effect.
It's not that simple. I spent some time last week trying to bisect the issue from upstream code and I couldn't. Everything right down to 2.17 seems to work correctly when in F21 and that sounds wrong. I'm going to try this again, this time on a rhel-7 box.
Comment 7Siddhesh Poyarekar
2015-03-09 18:15:05 UTC
... and we have a winner, it is:
https://sourceware.org/bugzilla/show_bug.cgi?id=17079
which was fixed by:
commit ac60763eac3d43b7234dd21286ad3ec3f17957fc
Author: Andreas Schwab <schwab>
Date: Mon Jun 23 10:24:45 2014 +0200
Don't ignore too long lines in nss_files (BZ #17079)
I broke it in rhel-7.0 when I backported the buggy patch.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHSA-2016-2573.html
Created attachment 897322 [details] Test program, takes optional user name ("root") and initial buffer size (4) as arguments Description of problem: In glibc-2.17-c758a686/nss/nss_files/files-XXX.c, in get_contents(), the loop appears to be checking for a too-small passed-in buffer incorrectly, in that it assigns 0xff to the final byte in the buffer after passing the buffer to fgets_unlocked instead of before. Version-Release number of selected component (if applicable): glibc-2.17-55.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Call getpwnam_r() with bufsize set to a small number (4 in my test). Actual results: getpwnam_r() returns 0 Expected results: getpwnam_r() returns ERANGE