netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: "liujian (CE)" <liujian56@huawei.com>, Martin KaFai Lau <kafai@fb.com>
Cc: "ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"songliubraving@fb.com" <songliubraving@fb.com>,
	"yhs@fb.com" <yhs@fb.com>,
	"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
	"kpsingh@kernel.org" <kpsingh@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"sdf@google.com" <sdf@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: RE: [PATCH bpf-next] net: Use skb->len to check the validity of the parameters in bpf_skb_load_bytes
Date: Tue, 15 Mar 2022 21:00:09 -0700	[thread overview]
Message-ID: <623160c966680_94df20819@john.notmuch> (raw)
In-Reply-To: <4f937ace70a3458580c6242fa68ea549@huawei.com>

liujian (CE) wrote:
> 
> 
> > -----Original Message-----
> > From: Martin KaFai Lau [mailto:kafai@fb.com]
> > Sent: Wednesday, March 16, 2022 3:58 AM
> > To: liujian (CE) <liujian56@huawei.com>
> > Cc: ast@kernel.org; daniel@iogearbox.net; andrii@kernel.org;
> > songliubraving@fb.com; yhs@fb.com; john.fastabend@gmail.com;
> > kpsingh@kernel.org; davem@davemloft.net; kuba@kernel.org;
> > sdf@google.com; netdev@vger.kernel.org; bpf@vger.kernel.org
> > Subject: Re: [PATCH bpf-next] net: Use skb->len to check the validity of the
> > parameters in bpf_skb_load_bytes
> > 
> > On Tue, Mar 15, 2022 at 08:39:16PM +0800, Liu Jian wrote:
> > > The data length of skb frags + frag_list may be greater than 0xffff,
> > > so here use skb->len to check the validity of the parameters.
> > What is the use case that needs to look beyond 0xffff ?

> I use sockmap with strparser, the stm->strp.offset (the begin of one
> application layer protocol message) maybe beyond 0xffff, but i need
> load the message head to do something.

This would explain skb_load_bytes but not the other two right? Also
if we are doing this why not just remove those two checks in
flow_dissector_load() I think skb_header_pointer() does duplicate
checks. Please check.

  reply	other threads:[~2022-03-16  4:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 12:39 [PATCH bpf-next] net: Use skb->len to check the validity of the parameters in bpf_skb_load_bytes Liu Jian
2022-03-15 19:58 ` Martin KaFai Lau
2022-03-16  1:09   ` liujian (CE)
2022-03-16  4:00     ` John Fastabend [this message]
2022-03-16 13:08       ` liujian (CE)
2022-03-16 15:09         ` Stanislav Fomichev
2022-03-17 14:08           ` liujian (CE)

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=623160c966680_94df20819@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=liujian56@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).