From: John Fastabend <john.fastabend@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net
Cc: netdev@vger.kernel.org, john.fastabend@gmail.com
Subject: [PATCH bpf-next 2/8] bpf: sk_msg, improve offset chk in _is_valid_access
Date: Thu, 20 Dec 2018 11:35:30 -0800 [thread overview]
Message-ID: <1545334536-766-3-git-send-email-john.fastabend@gmail.com> (raw)
In-Reply-To: <1545334536-766-1-git-send-email-john.fastabend@gmail.com>
The check for max offset in sk_msg_is_valid_access uses sizeof()
which is incorrect because it would allow accessing possibly
past the end of the struct in the padded case. Further, it doesn't
preclude accessing any padding that may be added in the middle of
a struct. All told this makes it fragile to rely on.
To fix this explicitly check offsets with fields using the
bpf_ctx_range() and bpf_ctx_range_till() macros.
For reference the current structure layout looks as follows (reported
by pahole)
struct sk_msg_md {
union {
void * data; /* 8 */
}; /* 0 8 */
union {
void * data_end; /* 8 */
}; /* 8 8 */
__u32 family; /* 16 4 */
__u32 remote_ip4; /* 20 4 */
__u32 local_ip4; /* 24 4 */
__u32 remote_ip6[4]; /* 28 16 */
__u32 local_ip6[4]; /* 44 16 */
__u32 remote_port; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 local_port; /* 64 4 */
__u32 size; /* 68 4 */
/* size: 72, cachelines: 2, members: 10 */
/* last cacheline: 8 bytes */
};
So there should be no padding at the moment but fixing this now
prevents future errors.
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/core/filter.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 3a3b217..6bd9f08 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6313,6 +6313,9 @@ static bool sk_msg_is_valid_access(int off, int size,
if (type == BPF_WRITE)
return false;
+ if (off % size != 0)
+ return false;
+
switch (off) {
case offsetof(struct sk_msg_md, data):
info->reg_type = PTR_TO_PACKET;
@@ -6324,16 +6327,20 @@ static bool sk_msg_is_valid_access(int off, int size,
if (size != sizeof(__u64))
return false;
break;
- default:
+ case bpf_ctx_range(struct sk_msg_md, family):
+ case bpf_ctx_range(struct sk_msg_md, remote_ip4):
+ case bpf_ctx_range(struct sk_msg_md, local_ip4):
+ case bpf_ctx_range_till(struct sk_msg_md, remote_ip6[0], remote_ip6[3]):
+ case bpf_ctx_range_till(struct sk_msg_md, local_ip6[0], local_ip6[3]):
+ case bpf_ctx_range(struct sk_msg_md, remote_port):
+ case bpf_ctx_range(struct sk_msg_md, local_port):
+ case bpf_ctx_range(struct sk_msg_md, size):
if (size != sizeof(__u32))
return false;
- }
-
- if (off < 0 || off >= sizeof(struct sk_msg_md))
- return false;
- if (off % size != 0)
+ break;
+ default:
return false;
-
+ }
return true;
}
--
2.7.4
next prev parent reply other threads:[~2018-12-20 19:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 19:35 [PATCH bpf-next 0/8] sockmap fixes/improvments for bpf-next John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 1/8] bpf: sk_msg, fix sk_msg_md access past end test John Fastabend
2018-12-20 19:35 ` John Fastabend [this message]
2018-12-20 19:35 ` [PATCH bpf-next 3/8] bpf: skmsg, replace comments with BUILD bug John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 4/8] bpf: skb_verdict, support SK_PASS on RX BPF path John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 5/8] bpf: sk_msg, fix socket data_ready events John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 6/8] bpf: sk_msg, zap ingress queue on psock down John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 7/8] bpf: sk_msg, sock{map|hash} redirect through ULP John Fastabend
2018-12-20 19:35 ` [PATCH bpf-next 8/8] bpf: tls_sw, init TLS ULP removes BPF proto hooks John Fastabend
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=1545334536-766-3-git-send-email-john.fastabend@gmail.com \
--to=john.fastabend@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
/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).