Bug 113347 - SIGSEGV in krb5kdc at foreachaddr.c:205 (NULL reference)
SIGSEGV in krb5kdc at foreachaddr.c:205 (NULL reference)
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
1
i386 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 113558 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-12 17:25 EST by Kuba Ober
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-12 09:16:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A makeshift fix which makes the problem go away (834 bytes, patch)
2004-01-12 17:27 EST, Kuba Ober
no flags Details | Diff

  None (edit)
Description Kuba Ober 2004-01-12 17:25:41 EST
Description of problem: 
There's a bug in src/include/foreachaddr.c. It's manifests itself 
around line 205, although the bug is really present in a few places. 
The ifp->ifaddr may be zero, and they get referenced in ifequal -> 
SIGSEGV. 
 
Version-Release number of selected component (if applicable): 
1.3.1-7 
 
How reproducible: 
Happens upon krb5kdc startup (only), with following network 
interfaces: 
eth0 lo ppp0 (ifconfig lists them in that order) 
 
Steps to Reproduce: 
1. service krb5kdc start 
   
Actual results: 
FAILED 
 
Expected results: 
OK 
 
Additional info: 
A clean /var/log/krb5kdc.log shows (after krb5kdc bombed out) 
setting up network... 
setting up network... 
skipping unrecognized local address family 17 
skipping unrecognized local address family 17
Comment 1 Kuba Ober 2004-01-12 17:27:27 EST
Created attachment 96908 [details]
A makeshift fix which makes the problem go away

The attached patch fixes the problem for me. It's a makeshift fix, the problem
should be investigated and a proper solution found.
Comment 2 Kuba Ober 2004-01-12 17:31:39 EST
It may be useful to know when did the error manifest itself: 
A working, up-to-date RedHat 9 server with running krb5kdc was 
upgraded to Fedora Core 1. After updating all the packages, as well 
as applying the updated modules, the system was rebooted. krb5kdc 
didn't want to start up (showed [FAILED]). 
 
FYI: This is a stable system, rpm -Va passes w/o anything out of the 
ordinary, memtest86 w/extensive tests OK for 96 hours. Nothing 
unusual I guess. IPV4 only, redhat .i686 kernel, everything really 
stock. 
Comment 3 Kuba Ober 2004-01-12 17:33:08 EST
Obviously, the krb5 rpm version is 1.3.1-6 :) 
Comment 4 Nalin Dahyabhai 2004-01-19 14:17:50 EST
*** Bug 113558 has been marked as a duplicate of this bug. ***
Comment 5 Nalin Dahyabhai 2004-01-19 15:44:37 EST
I've only been able to reproduce this in a weird setup (with a network
connection up, but configured without an address).  Can you please
append the output of either 'ip address list' or 'ifconfig -a' so that
I can make sure that's what's going on for you as well?
Comment 6 Kuba Ober 2004-01-19 16:18:03 EST
This is my network setup where the problem reproduceably recurs. Note 
that this system runs fedora kernel and thus has IPV6 available, 
although not necessarily configured. I didn't do anything even 
remotely IPV6 related on this machine, though. 
 
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 
    link/ether 00:d0:b7:17:39:3e brd ff:ff:ff:ff:ff:ff 
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1656 qdisc pfifo_fast 
qlen 3 
    link/ppp 
    inet 213.25.212.169/32 scope global ppp0 
eth0      Link encap:Ethernet  HWaddr 00:D0:B7:17:39:3E 
          inet addr:192.168.0.1  Bcast:192.168.0.255  
Mask:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          RX packets:13891679 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:14152475 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:1000 
          RX bytes:591735880 (564.3 Mb)  TX bytes:1513154826 (1443.0 
Mb) 
          Interrupt:12 Base address:0xcc00 Memory:dffdf000-dffdf038 
 
lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0 
          UP LOOPBACK RUNNING  MTU:16436  Metric:1 
          RX packets:290810 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:290810 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:0 
          RX bytes:92174788 (87.9 Mb)  TX bytes:92174788 (87.9 Mb) 
 
ppp0      Link encap:Point-to-Point Protocol 
          inet addr:213.25.212.169  P-t-P:213.25.212.169  
Mask:255.255.255.255 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1656  Metric:1 
          RX packets:1133681 errors:53 dropped:0 overruns:0 frame:0 
          TX packets:933852 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:3 
          RX bytes:563438740 (537.3 Mb)  TX bytes:110723212 (105.5 
Mb) 
 
Comment 7 Nalin Dahyabhai 2004-02-03 16:33:15 EST
Hmm. By the looks of it, you shouldn't even be hitting that problem on
your system -- every interface has at least one network address.

Please try 1.3.1-9 from the development tree, which has a patch which
is very similar to the one submitted in
http://mailman.mit.edu/pipermail/krb5-bugs/2004-January/002152.html
Comment 8 Paul Jakma 2004-02-03 20:17:56 EST
His interfaces all have v4 addresses, however they might not have v6
addresses, which appears to be the source of the problem - eg the sit0
device is a common case.

The patch at the URL above fixes the problem here.
Comment 9 Matthew Miller 2006-07-11 13:46:29 EDT
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.

Thanks!

NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.

Comment 10 Paul Jakma 2006-07-12 05:44:14 EDT
Long fixed in MIT Krb5 sources.
Comment 11 Matthew Miller 2006-07-12 09:16:21 EDT
So, resolved upstream?

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