[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ec99ea3-6ab1-eee4-be60-992cf2f9cd45@nvidia.com>
Date: Thu, 10 Jun 2021 10:05:29 +0300
From: Maxim Mikityanskiy <maximmi@...dia.com>
To: Florian Westphal <fw@...len.de>
CC: Mat Martineau <mathew.j.martineau@...ux.intel.com>,
Matthieu Baerts <matthieu.baerts@...sares.net>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Toke Høiland-Jørgensen <toke@...e.dk>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Patrick McHardy <kaber@...sh.net>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Paolo Abeni <pabeni@...hat.com>,
Christoph Paasch <cpaasch@...le.com>,
Peter Krystad <peter.krystad@...ux.intel.com>,
Young Xiao <92siuyang@...il.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net 1/3] netfilter: synproxy: Fix out of bounds when
parsing TCP options
On 2021-06-09 17:51, Florian Westphal wrote:
> Maxim Mikityanskiy <maximmi@...dia.com> wrote:
>> The TCP option parser in synproxy (synproxy_parse_options) could read
>> one byte out of bounds. When the length is 1, the execution flow gets
>> into the loop, reads one byte of the opcode, and if the opcode is
>> neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
>> the length of 1.
>>
>> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack
>> out of bounds when parsing TCP options.").
>>
>> Cc: Young Xiao <92siuyang@...il.com>
>> Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target")
>> Signed-off-by: Maxim Mikityanskiy <maximmi@...dia.com>
>> ---
>> net/netfilter/nf_synproxy_core.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
>> index b100c04a0e43..621eb5ef9727 100644
>> --- a/net/netfilter/nf_synproxy_core.c
>> +++ b/net/netfilter/nf_synproxy_core.c
>> @@ -47,6 +47,8 @@ synproxy_parse_options(const struct sk_buff *skb, unsigned int doff,
>> length--;
>> continue;
>> default:
>> + if (length < 2)
>> + return true;
>
> Would you mind a v2 that also rejects bogus th->doff value when
> computing the length?
Could you elaborate? The length is a signed int calculated as `(th->doff
* 4) - sizeof(*th)`. Invalid doff values (0..4) lead to negative length,
so we never enter the loop. Or are you concerned of passing a negative
length to skb_header_pointer?
>
> Thanks.
>
Powered by blists - more mailing lists