Bug 113347 - SIGSEGV in krb5kdc at foreachaddr.c:205 (NULL reference)
Summary: SIGSEGV in krb5kdc at foreachaddr.c:205 (NULL reference)
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
: 113558 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-12 22:25 UTC by Kuba Ober
Modified: 2008-08-02 23:40 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-07-12 13:16:21 UTC

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

Description Kuba Ober 2004-01-12 22:25:41 UTC
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 -> 
Version-Release number of selected component (if applicable): 
How reproducible: 
Happens upon krb5kdc startup (only), with following network 
eth0 lo ppp0 (ifconfig lists them in that order) 
Steps to Reproduce: 
1. service krb5kdc start 
Actual results: 
Expected results: 
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 22:27:27 UTC
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 22:31:39 UTC
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 

Comment 3 Kuba Ober 2004-01-12 22:33:08 UTC
Obviously, the krb5 rpm version is 1.3.1-6 :) 

Comment 4 Nalin Dahyabhai 2004-01-19 19:17:50 UTC
*** Bug 113558 has been marked as a duplicate of this bug. ***

Comment 5 Nalin Dahyabhai 2004-01-19 20:44:37 UTC
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 21:18:03 UTC
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 brd 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 brd scope global eth0 
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1656 qdisc pfifo_fast 
qlen 3 
    inet scope global ppp0 
eth0      Link encap:Ethernet  HWaddr 00:D0:B7:17:39:3E 
          inet addr:  Bcast:  
          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 
          Interrupt:12 Base address:0xcc00 Memory:dffdf000-dffdf038 
lo        Link encap:Local Loopback 
          inet addr:  Mask: 
          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:  P-t-P:  
          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 

Comment 7 Nalin Dahyabhai 2004-02-03 21:33:15 UTC
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

Comment 8 Paul Jakma 2004-02-04 01:17:56 UTC
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 17:46:29 UTC
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.


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 09:44:14 UTC
Long fixed in MIT Krb5 sources.

Comment 11 Matthew Miller 2006-07-12 13:16:21 UTC
So, resolved upstream?

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