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]

Message-Id: <20090204.010029.12969718.davem@davemloft.net>
Date:	Wed, 04 Feb 2009 01:00:29 -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: Wed, 04 Feb 2009 09:55:04 +0100

> On Tue, 2009-02-03 at 15:38 -0800, David Miller wrote:
> > 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.
> 
> Yes, but this only happens on the NIU/netpune NIC.  I works with the igb
> driver, I have both a 82575 and a 82576 NIC.

Right, and what's unique about NIU is that NIU won't prepull
the protocol headers into the linear area on receive.

At the point when IPMR is dealing with potentially forwarding
the frame, the UDP headers aren't yet pulled into the linear
area.  UDP input will do that with it's pskb_may_pull() call.

I think this is the critical bit, and some part of the IPMR
code makes assumptions about all of the protocol headers being
pulled into the linear SKB area when it executes.

I really don't have time to track this down, so what I suggest
you do is add logging to UDP multicast packets at various
locations looking for the UDP header length in the paged SKB
area to go illegal.  Move your probe points around to narrow
down the culprit.

Good luck.
--
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