netdev - Re: [PANIC] lro + iscsi or lro + skb text search causes panic

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:	Mon, 26 Jan 2009 21:52:06 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	michaelc@...wisc.edu, jesse.brandeburg@...el.com,
	netdev@...r.kernel.org, olaf.kirch@...cle.com, tgraf@...g.ch,
	kkeil@...e.de
Subject: Re: [PANIC] lro + iscsi or lro + skb text search causes panic

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Tue, 27 Jan 2009 09:30:22 +1100

> net: Fix frag_list handling in skb_seq_read
> 
> The frag_list handling was broken in skb_seq_read:
> 
> 1) We didn't add the stepped offset when looking at the head
> are of fragments other than the first.
> 
> 2) We didn't take the stepped offset away when setting the data
> pointer in the head area.
> 
> 3) The frag index wasn't reset.
> 
> This patch fixes both issues.
> 
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

I see, the code is only clearing the fragment index when it's
advancing from one SKB to the next while already in the middle of a
->frag_list, not when transitioning past the root skb in such a list.

I bet some weird cases happen when "consumed" it's advanced by
the caller the entire length of data returned by the previous
skb_seq_read().

It all seems to be designed to work for that case, however.

Anyways, Herbert's patch looks definitely correct but until
we've gotten these crashes and hangs solved I don't want
to apply it.
--
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