netdev - Re: [PATCH 1/2] [IPV4] UDP: Always checksum even if without socket filter

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: <20071117.160926.232024605.davem@davemloft.net>
Date:	Sat, 17 Nov 2007 16:09:26 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	andi@...stfloor.org
Cc:	wangchen@...fujitsu.com, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] [IPV4] UDP: Always checksum even if without socket
 filter

From: Andi Kleen <andi@...stfloor.org>
Date: Sat, 17 Nov 2007 14:18:46 +0100

> Wang Chen <wangchen@...fujitsu.com> writes:
> 
> > Herbert Xu said the following on 2007-11-16 12:11:
> >> Wang Chen <wangchen@...fujitsu.com> wrote:
> >>> So, I think the checksum in udp_queue_rcv_skb() actually does
> >>> the work, not that in udp_recvmsg() and udp_poll().
> >>>
> >>> If I am wrong, please point out.
> >> 
> >> We may have a bug in the accounting area.  Check the recent
> >> patch made to UDP/IPv6 which is probably needed here as well.
> >> 
> >
> > Like dave said, decrementing the InDataGrams in this case is an
> > option.
> > I will check the same place of UDP/IPv6.
> 
> And like Benny pointed out it's probably a bad idea because
> decrementing counters will be an unexpected ABI change for monitoring 
> programs who have no other way to detect overflow.

We could defer the increment until we check the checksum,
but that is likely to break even more things because people
(as Wang Chen did initially) will send a packet to some
port with an app that doesn't eat the packets, and expect the
InDatagrams counter to increase once the stack eats the packet.
But it won't until the application does the read.

All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP application overflow detection issue.

-
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