netdev - Re: BUG: NIU driver: strange issues with multicast "UDP: short packet"

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Feb 2009 15:38:53 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	jdb@...x.dk
Cc:	netdev@...r.kernel.org
Subject: Re: BUG: NIU driver: strange issues with multicast "UDP: short
 packet"

From: Jesper Dangaard Brouer <jdb@...x.dk>
Date: Tue, 03 Feb 2009 14:38:20 +0100

>   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
>   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931

The UDP header length field is garbage in all of these packets.

In the first two packets here, the source and dest ports are
both zero.  This is also garbage.,

> Tcpdumping the packets, the contents of the packets are correct.

So something corrupts the packet on the way to UDP input.

> The next strange thing is that I can make the log messages go away, if I
> setup a static multicast route out another interface.
> 
>   smcroute -a eth52 81.161.2.106 233.123.173.7 eth21

That could be a good clue.

Do you happen to have multicast routing enabled on this machine?  If
the multicast destination is non-local and IN_DEV_FORWARD is set on
the interface, that puts the packet through ip_mr_input.

ip_mr_input() will clone the SKB if it should be delivered locally
as well as be forwarded.

If the packet does get multicast forwarded, there is all kinds of
funny code that mangles the packet, for example ipmr_cache_report().

Any of this could be corrupting what UDP ends up seeing.

To be honest all of the SKB handling in the ipmr.c file is very scary.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html