From: Jarek Poplawski <jarkao2@gmail.com>
To: Ralph Loader <suckfish@ihug.co.nz>
Cc: netdev@vger.kernel.org
Subject: Re: Buglet in net/pkt_cls.h pointer handling.
Date: Mon, 20 Dec 2010 09:54:40 +0000 [thread overview]
Message-ID: <20101220095440.GA7977@ff.dom.local> (raw)
In-Reply-To: <20101216215627.43f34977.suckfish@ihug.co.nz>
On 2010-12-16 09:56, Ralph Loader wrote:
> Hi,
>
> tcf_valid_offset() in net/pkt_cls.h appears to have a couple of
> problems (obvious patch below):
>
> (a) there is no check for overflow in the pointer arithmetic.
> (b) the pointers are presumably likely to be normally valid, so the
> hint should be 'likely()' not 'unlikely()'.
Hi,
Your 'unlikely()' concern seems likely right. Forcing 'len >= 0' in
your patch is another question. Anyway, I wonder why don't you add
your "Signed-off-by", and Cc people who know these things: the
'TC CLASSIFIER' maintainer (as in MAINTAINERS) and the ematch author?
Cheers,
Jarek P.
>
> The offsets used to construct the arguments to that function, e.g., as
> called in net/sched/em_u32.c, I think come from user-space & in theory
> could be crafted to cause an invalid pointer deref if ptr+len overflows?
>
> Possibly the '<' and '>' in that function should be '<=' and '>='
> also. I'm not familiar enough with the data-structures to be sure.
>
> Also a question: in em_u32.c em_u32_match(), and in cls_u32.c
> u32_classify(), we dereference pointers that have had an offset
> (originally from user space) added to them. I can't see anything that
> keeps those pointers aligned. Is that a problem on architectures that
> don't support unaligned pointers, or am I missing something?
>
> Cheers,
> Ralph.
>
>
> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> index dd3031a..99a2d7b 100644
> --- a/include/net/pkt_cls.h
> +++ b/include/net/pkt_cls.h
> @@ -323,7 +323,7 @@ static inline unsigned char * tcf_get_base_ptr(struct sk_buff *skb, int layer)
> static inline int tcf_valid_offset(const struct sk_buff *skb,
> const unsigned char *ptr, const int len)
> {
> - return unlikely((ptr + len) < skb_tail_pointer(skb) && ptr > skb->head);
> + return likely((ptr + len) < skb_tail_pointer(skb) && ptr > skb->head && ptr <= ptr + len);
> }
>
> #ifdef CONFIG_NET_CLS_IND
next prev parent reply other threads:[~2010-12-20 9:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 8:56 Buglet in net/pkt_cls.h pointer handling Ralph Loader
2010-12-20 9:54 ` Jarek Poplawski [this message]
2010-12-21 20:57 ` David Miller
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=20101220095440.GA7977@ff.dom.local \
--to=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=suckfish@ihug.co.nz \
/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.