All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: David Miller <davem@davemloft.net>,
	Willem de Bruijn <willemb@google.com>,
	Eric Dumazet <edumazet@google.com>,
	netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	andreyknvl <andreyknvl@google.com>
Subject: KASAN poisoning for skb linear data
Date: Mon, 15 Jan 2018 15:15:04 +0100	[thread overview]
Message-ID: <CACT4Y+Z6SS2AzYnMjbx_cmrataCLUhdjAx8XyYAnTMdVzndH5w@mail.gmail.com> (raw)

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

             reply	other threads:[~2018-01-15 14:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 14:15 Dmitry Vyukov [this message]
2018-03-08  9:20 ` KASAN poisoning for skb linear data Dmitry Vyukov
2018-03-08 15:43   ` Stephen Hemminger
2018-11-17  0:52   ` Dmitry Vyukov
2018-03-08 15:45 ` Stephen Hemminger
2018-03-08 15:59   ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+Z6SS2AzYnMjbx_cmrataCLUhdjAx8XyYAnTMdVzndH5w@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=andreyknvl@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.