Re: KASAN poisoning for skb linear data

[Dmitry Vyukov]

On Thu, Mar 8, 2018 at 4:45 PM, Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 15 Jan 2018 15:15:04 +0100
> Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
>> Hi,
>>
>> As far as I understand pskb_may_pull() plays important role in packet
>> parsing for all protocols. And we did custom fragmentation of packets
>> emitted via tun (IFF_NAPI_FRAGS). However, it seems that it does not
>> give any results (bugs found), and I think the reason for this is that
>> linear data is rounded up and is usually quite large. So if a parsing
>> function does pskb_may_pull(1), or does not do it at all, it can
>> usually access more and it will go unnoticed. KASAN has an ability to
>> do custom poisoning: it can poison/unpoison any memory range, and then
>> detect any reads/writes to that range. What do you think about adding
>> custom KASAN poisoning to pskb_may_pull() and switching it to
>> non-eager mode (pull only what was requested) under KASAN? Do you
>> think it has potential for finding important bugs? What amount of work
>> is this?
>>
>> Thanks
>
> Also, kernel networking only deals with in-tree upstream code.
> Any problems with infrastructure for custom code are your problem
> to deal with, not our problem.


This is 100% about upstream code. The issue for me, it is not in
networking component.
I've filed an issue because kernel mailing lists are used mostly for
patches, everything else is immediately lost (e.g. like this one).