Bug 89448 - getaddrinfo segv - unitialized structure?
Summary: getaddrinfo segv - unitialized structure?
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-22 23:08 UTC by Ben Woodard
Modified: 2016-11-24 15:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 18:27:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program that illustrates the problem (824 bytes, text/plain)
2003-04-22 23:09 UTC, Ben Woodard
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:325 normal SHIPPED_LIVE : Updated glibc packages provide security and bug fixes 2003-11-12 05:00:00 UTC

Description Ben Woodard 2003-04-22 23:08:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
From: 	Jim Garlick <garlick@llnl.gov>
Reply-To: 	chaos-dev@lists.llnl.gov
To: 	uselton2@llnl.gov
Cc: 	chaos-dev@lists.llnl.gov
Subject: 	powerman bug, not.
Date: 	Mon, 21 Apr 2003 11:47:19 -0700 (PDT)	
Hey Andrew, I think I found that powerman bug on toad.  It actually looks like
a bug in getaddrinfo where maybe it is using some stack storage uninitialized
and expecting it to be zeroed.  I found in powerman that zeroing 330 bytes of
stack before calling getaddrinfo made the core dumps go away, and that a test
program (below) that only calls getaddrinfo could be made to core dump by
setting 330 bytes of stack to 0xff before calling getaddrinfo.  I didn't take
it any further than that (e.g. finding the specific bug in getaddrinfo)
because this was enough to convince me it was not a powerman problem.

This only reproduces on RedHat 9, not 7.3.  The specific glibc on RedHat 9
that seems broken is glibc-2.3.2-27.9.  Ben could you report this?

Thanks,

Jim

____________________
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void _dirty_stack(void)
{
        char _dummy[330]; /* 320 nope, 330 yes */
        int i;

        for (i = 0; i < (sizeof(_dummy)/sizeof(_dummy[0])); i++)
                _dummy[i] = 0xff;
}

int main(int argc, char *argv[])
{
        struct addrinfo hints, *ai;
        int res;

        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_flags = AI_CANONNAME;
        hints.ai_family = AF_INET;
        hints.ai_socktype = SOCK_STREAM;

        _dirty_stack();

        res = getaddrinfo("localhost", "telnet", &hints, &ai);

        printf("result: %s\n", res == 0 ? "success" : gai_strerror(res));

        if (res == 0)
                freeaddrinfo(ai);

        exit(0);
}


Version-Release number of selected component (if applicable):
glibc-2.3.2-27.9

How reproducible:
Always

Steps to Reproduce:
1. run the test program above
2.
3.
    

Actual Results:  it crashes

Expected Results:  it works

Additional info:

Comment 1 Ben Woodard 2003-04-22 23:09:54 UTC
Created attachment 91234 [details]
test program that illustrates the problem

This is just an attached version of the file from above.

Comment 2 Jakub Jelinek 2003-04-23 09:59:40 UTC
Should be fixed in http://sources.redhat.com/ml/libc-hacker/2003-04/msg00059.html.

Comment 3 Ulrich Drepper 2003-04-23 18:27:43 UTC
Fixed in the official glibc version, will be in the next glibc RPM.

Comment 4 Ulrich Drepper 2003-11-04 21:41:29 UTC
Try the test release of the RHL9 errata at

  ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.4/           
                                                                    



Note You need to log in before you can comment on or make changes to this bug.