netdev - Re: [PATCHv2 net 2/3] openvswitch: Treat IP_CT

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, 19 Oct 2015 00:07:09 -0700
From:	Joe Stringer <joestringer@...ira.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	Pravin Shelar <pshelar@...ira.com>
Subject: Re: [PATCHv2 net 2/3] openvswitch: Treat IP_CT_RELATED as new

On 17 October 2015 at 00:52, Thomas Graf <tgraf@...g.ch> wrote:
> On 10/16/15 at 11:08am, Joe Stringer wrote:
>> New, related connections are marked as such as part of ovs_ct_lookup(),
>> but they are not marked as "new" if the commit flag is used. Make this
>> consistent by treating IP_CT_RELATED as new as well.
>>
>> Reported-by: Jarno Rajahalme <jrajahalme@...ira.com>
>> Signed-off-by: Joe Stringer <joestringer@...ira.com>
>> Acked-by: Pravin B Shelar <pshelar@...ira.com>
>> ---
>> v2: Acked.
>> ---
>>  net/openvswitch/conntrack.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>> index 80bf702715bb..480dbb9095b7 100644
>> --- a/net/openvswitch/conntrack.c
>> +++ b/net/openvswitch/conntrack.c
>> @@ -86,6 +86,8 @@ static u8 ovs_ct_get_state(enum ip_conntrack_info ctinfo)
>>               ct_state |= OVS_CS_F_ESTABLISHED;
>>               break;
>>       case IP_CT_RELATED:
>> +             ct_state |= OVS_CS_F_NEW;
>> +             /* Fall through */
>>       case IP_CT_RELATED_REPLY:
>>               ct_state |= OVS_CS_F_RELATED;
>>               break;
>
> I'm probably missing something obvious. Why is the reply direction
> not considered NEW? Wouldn't this consider an ICMPv6 as related+new
> depending on simply the direction?

My thoughts were along the lines "If something is a reply, that
implies that state is held, and therefore it cannot be NEW (where NEW
means no state is available)". However, if you consider that the
'related' connection is an independent connection with its own state,
but the 'reply' bit refers to the original connection, my original
premise breaks. Furthermore, looking at how it's used in netfilter
core and the ICMP proto handler, it looks like both of these cases
should be considered NEW. I can respin.

Do you have a specific case in mind here? It would be useful for
extending the OVS testsuite.
--
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