==
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT 2016
25-26 AUGUST
TORONTO, CANADA
Make sure the table names via getsockopt GET_ENTRIES is nul-terminated
in ebtables and all the x_tables variants and their respective compat
code. Uncovered by KASAN.
Reported-by: Baozeng Ding
Signed-off-by: Pablo Neira Ayuso
---
On Wed, Mar 23, 2016 at 10:27:30PM +0800, Liping Zhang wrote:
> diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c
> b/net/ipv4/netfilter/ipt_SYNPROXY.c
> index 7b8fbb3..6b4f501 100644
> --- a/net/ipv4/netfilter/ipt_SYNPROXY.c
> +++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
> @@ -18,10 +18,10 @@
>
On Tue, Mar 22, 2016 at 06:02:51PM +0100, Florian Westphal wrote:
> We have targets and standard targets -- the latter carries a verdict, so we
> must check the standard size as well here -- later functions access t->verdict
> which otherwise can point after the blob end.
Applied to nf, thanks.
On Tue, Mar 22, 2016 at 06:02:50PM +0100, Florian Westphal wrote:
> Otherwise this function may read data beyond the ruleset blob.
Also applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More
On Tue, Mar 22, 2016 at 06:02:52PM +0100, Florian Westphal wrote:
> Ben Hawkes says:
>
> In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
> is possible for a user-supplied ipt_entry structure to have a large
> next_offset field. This field is not bounds checked prior to
On Tue, Mar 22, 2016 at 06:02:49PM +0100, Florian Westphal wrote:
> We should check that e->target_offset is sane before
> mark_source_chains gets called since it will fetch the target entry
> for loop detection.
Applied, thanks Florian.
--
To unsubscribe from this list: send the line
On Thu, Mar 24, 2016 at 10:00:02AM +0200, Nikolay Borisov wrote:
> I've been running production kernels in production with those changes
> and so far I haven't observed a single crash resulting from this.
> Furthermore, I believe that all the call sites of synproxy_build_ip
> should have the skb
On 03/24/2016 10:25 AM, 张李平 wrote:
> At 2016-03-24 16:00:02, "Nikolay Borisov" wrote:
>> I've been running production kernels in production with those changes
>> and so far I haven't observed a single crash resulting from this.
>
> Did you run the test with the CONFIG_NET_NS
I've been running production kernels in production with those changes
and so far I haven't observed a single crash resulting from this.
Furthermore, I believe that all the call sites of synproxy_build_ip
should have the skb associated with a valid tcp socket, which must have
originated from a
10 matches
Mail list logo