linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaud Giersch <arnaud.giersch@free.fr>
To: davem@caip.rutgers.edu, Eric.Schenk@dna.lth.se, alan@lxorguk.ukuu.org.uk
Cc: linux-kernel@vger.kernel.org
Subject: [PROBLEM+PATCH] linux 2.[45].x: negative inode numbers in /proc/net/*
Date: 20 Feb 2002 21:06:39 +0100	[thread overview]
Message-ID: <871yff535c.fsf@free.fr> (raw)


Hello,

I think I found a little but annoying bug in the /proc/net reporting
functions for various types of sockets: when the inode numbers become
large enough, they are printed as negative values.

For example in /proc/net/{udp,unix} (kernel 2.4.17, i686):

        $ cat /proc/net/udp
          sl  ...  inode
        [...]
          79: ...  -1834994132 2 dba94580
        [...]

        $ cat /proc/net/unix
        Num       ...  Inode Path
        [...]
        c35b1580: ...  -2123437312 /tmp/.X11-unix/X0
        ce571040: ...  -2123437313
        [...]

I found it because it causes netstat <= 1.60 to segfault (there was of
course a bug in netstat too).

This can be reproduced using brute force: keep opening and closing
sockets during enough time in order to have inode numbers become
greater than 2^31 (this takes a few hours on my AMD Duron 800).

The problem exists apparently in all 2.4.x and 2.5.x kernel versions.

The reason is that the inode numbers are printed as signed long ("%ld"
printf format) instead of unsigned long ("%lu" printf format) as it
should be.

I grep'ed the kernel source net subdirectory in order to find other
similar bugs. I found that it is present for {ipv4,ipv6}/{raw,udp} and
unix sockets.

Here is my patch against kernel version 2.4.17:

<======================================================================>
diff -Naur linux.orig/net/ipv4/raw.c linux/net/ipv4/raw.c
--- linux.orig/net/ipv4/raw.c	Wed Jul 11 01:11:43 2001
+++ linux/net/ipv4/raw.c	Tue Feb 19 23:06:45 2002
@@ -631,7 +631,7 @@
 	      srcp  = sp->num;
 
 	sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X"
-		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %ld %d %p",
+		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
 		i, src, srcp, dest, destp, sp->state, 
 		atomic_read(&sp->wmem_alloc), atomic_read(&sp->rmem_alloc),
 		0, 0L, 0,
diff -Naur linux.orig/net/ipv4/udp.c linux/net/ipv4/udp.c
--- linux.orig/net/ipv4/udp.c	Wed Oct 17 23:16:39 2001
+++ linux/net/ipv4/udp.c	Mon Feb 18 15:49:49 2002
@@ -957,7 +957,7 @@
 	destp = ntohs(sp->dport);
 	srcp  = ntohs(sp->sport);
 	sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X"
-		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %ld %d %p",
+		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
 		i, src, srcp, dest, destp, sp->state, 
 		atomic_read(&sp->wmem_alloc), atomic_read(&sp->rmem_alloc),
 		0, 0L, 0,
diff -Naur linux.orig/net/ipv6/raw.c linux/net/ipv6/raw.c
--- linux.orig/net/ipv6/raw.c	Thu Sep 20 23:12:56 2001
+++ linux/net/ipv6/raw.c	Tue Feb 19 23:10:33 2002
@@ -761,7 +761,7 @@
 	srcp  = sp->num;
 	sprintf(tmpbuf,
 		"%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
-		"%02X %08X:%08X %02X:%08lX %08X %5d %8d %ld %d %p",
+		"%02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
 		i,
 		src->s6_addr32[0], src->s6_addr32[1],
 		src->s6_addr32[2], src->s6_addr32[3], srcp,
diff -Naur linux.orig/net/ipv6/udp.c linux/net/ipv6/udp.c
--- linux.orig/net/ipv6/udp.c	Fri Sep  7 20:01:21 2001
+++ linux/net/ipv6/udp.c	Tue Feb 19 23:10:18 2002
@@ -916,7 +916,7 @@
 	srcp  = ntohs(sp->sport);
 	sprintf(tmpbuf,
 		"%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
-		"%02X %08X:%08X %02X:%08lX %08X %5d %8d %ld %d %p",
+		"%02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
 		i,
 		src->s6_addr32[0], src->s6_addr32[1],
 		src->s6_addr32[2], src->s6_addr32[3], srcp,
diff -Naur linux.orig/net/unix/af_unix.c linux/net/unix/af_unix.c
--- linux.orig/net/unix/af_unix.c	Fri Dec 21 18:42:06 2001
+++ linux/net/unix/af_unix.c	Mon Feb 18 22:01:29 2002
@@ -1742,7 +1742,7 @@
 	{
 		unix_state_rlock(s);
 
-		len+=sprintf(buffer+len,"%p: %08X %08X %08X %04X %02X %5ld",
+		len+=sprintf(buffer+len,"%p: %08X %08X %08X %04X %02X %5lu",
 			s,
 			atomic_read(&s->refcnt),
 			0,
<======================================================================>


Greetings
-- 
Arnaud

             reply	other threads:[~2002-02-20 20:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-20 20:06 Arnaud Giersch [this message]
2002-03-05 12:45 ` [PROBLEM+PATCH] linux 2.[45].x: negative inode numbers in /proc/net/* David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871yff535c.fsf@free.fr \
    --to=arnaud.giersch@free.fr \
    --cc=Eric.Schenk@dna.lth.se \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@caip.rutgers.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).