netdev - Re: [PATCH net 1/1] tipc: allow non-linear first fragment buffer

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

Date:	Wed, 21 Oct 2015 19:09:16 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jon.maloy@...csson.com
Cc:	netdev@...r.kernel.org, paul.gortmaker@...driver.com,
	parthasarathy.xx.bhuvaragan@...csson.com,
	richard.alpe@...csson.com, ying.xue@...driver.com,
	maloy@...jonn.com, tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net 1/1] tipc: allow non-linear first fragment buffer

From: Jon Maloy <jon.maloy@...csson.com>
Date: Mon, 19 Oct 2015 11:33:00 -0400

> The current code for message reassembly is erroneously assuming that
> the the first arriving fragment buffer always is linear, and then goes
> ahead resetting the fragment list of that buffer in anticipation of
> more arriving fragments.
> 
> However, if the buffer already happens to be non-linear, we will
> inadvertently drop the already attached fragment list, and later
> on trig a BUG() in __pskb_pull_tail().
> 
> We see this happen when running fragmented TIPC multicast across UDP,
> something made possible since
> commit d0f91938bede ("tipc: add ip/udp media type")
> 
> We fix this by not resetting the fragment list when the buffer is non-
> linear, and by initiatlizing our private fragment list tail pointer to
> the tail of the existing fragment list.
> 
> Fixes: commit d0f91938bede ("tipc: add ip/udp media type")
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied and queued up for -stable, thanks.
--
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