linux-kernel - strange bug with ip multicasting.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <72349780AFF0F849921FF8FFF8075A5007BBD2A5@NYWEXMB25.msad.ms.com>
Date:	Wed, 3 Oct 2007 14:22:11 -0400
From:	"Wu, Shao \(IT\)" <Shao.Wu@...ganstanley.com>
To:	<linux-kernel@...r.kernel.org>
Cc:	<swu001@...il.com>
Subject: strange bug with ip multicasting.

Summary: a random hanging bug when receiving multicast datagrams on
2.6.x kernels.
Keywards: hang, networking, kernel, multicast, recv, multicast loopback,
poll hang, select hang
Kernel version: 2.6.x
 
Full description of the problem:
-----------------------------------------------
 * This simple program demonstrates a bug in Linux kernel 2.6.x releases
(and
 * possibly 2.4 kernels also). I have tested this code on several 2.6
kernels
 * (RHEL 4.4, 4.5, 5.0 releases) all suffering the same bug. On Sun
Solaris 10,
 * however, it always behave correctly.
 *
 * This bug also affects select/poll's behavior as demonstrated in
CASE2.
 *
 * How to reproduce the bug...
 *
 *    Please make sure the multicast group address and the port number
are not
 *    currently in use on your test system. I use group address
239.255.1.1 and
 *    port number 12345 here.  Here are commands you can use to verify:
 *        netstat -gn
 *        netstat -an | grep 12345
 *    If you don't see port 12345 and group address 239.255.1.1 listed,
that is
 *    good.
 *
 * Test scenarios:
 * 1. Run one copy of this program, if you see it's running and
receiving its
 *    own messages, control-C out of it (because that is how it should
behave).
 *    And try again. If you try that a few times, you will see that this
program
 *    will hang on recv() function!  That is an incorrect behavior. This
program
 *    should always receive its own messages.
 *
 * 2. Follow scenario #1 until you get it hanging, open another window,
and run
 *    a second copy of this program. You will see both copies start
running and
 *    can receive each other's messages. That's a correct behavior --
the first
 *    datagram from the second copy takes the first copy of the process
out of
 *    hanging state.

Test program source file is attached. If you can't find the attached C++
source file, please send email to my personal email account at
swu001@...il.com and I'll send the testing code from there.
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

Download attachment "simplemcast.cc" of type "application/octet-stream" (5135 bytes)