netdev - Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull

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:	Tue, 1 Sep 2015 12:20:09 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull

On Tue, Sep 1, 2015 at 7:19 AM, Tom Herbert <tom@...bertland.com> wrote:
> On Mon, Aug 31, 2015 at 10:15 PM, Pravin Shelar <pshelar@...ira.com> wrote:
>> On Mon, Aug 31, 2015 at 9:12 PM, Tom Herbert <tom@...bertland.com> wrote:
>>> On Mon, Aug 31, 2015 at 3:55 PM, Pravin B Shelar <pshelar@...ira.com> wrote:
>>>> VXLAN device can receive skb with checksum partial. But the checksum
>>>> offset could be in outer header which is pulled on receive. Such skb
>>>> can cause the panic when checksum is calculated on skb. Following patch
>>>> fixes the bug by setting checksum unnecessary while pulling outer header.
>>>>
>>> Okay, I think I understand what you are doing. I suggest in the
>>> openvswitch path, if there is a checksum CHECKSUM_PARTIAL that refers
>>> to the outer headers which must have been verified at this point then
>>> set to CHECKSUM_NONE-- assuming CHECKSUM_UNNECESSARY on the inner
>>> header is not correct in this case. If the CHECKSUM_PARTIAL refers to
>>> the inner header then you can call skb_checksum_help to resolve an
>>> inner checksum.
>>>
>>
>> That would be OVS specific fix, But I do see skb_checksum_help()
>> called in multiple places outside OVS that could result in similar
>> kernel panic. Therefore I want to solve it up in networking stack
>> rather than in OVS.
>>
> Please try to reproduce this out of OVS from the top of the tree then
> and report down exactly where panic is occurring the code. Unlike most
> of the of the other cases where skb_checksum_help() is being called
> this in the RX path so skb is probably not pulled over the checksum
> offset for those. Even so, if the skb is pulled beyond the checksum
> offset then this should result in a negative offset in
> skb_checksum_start_offset(skb) which should be okay. It looks like
> this in itself should not be causing your panic.
>

ip_do_fragment() also calls skb_checksum_help() that can results in
similar panic. But it is not easy to reproduce it in this case due to
call site is in exception path.
The negative checksum offset can atleast cause assert failure in
skb_checksum_help(). I will send patch to fix that.
--
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