Message ID | 20210326160501.46234-1-lmb@cloudflare.com (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | BPF |
Headers | show |
Series | [bpf,v2,1/2] bpf: link: refuse non-O_RDWR flags in BPF_OBJ_GET | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for bpf |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | warning | 5 maintainers not CCed: yhs@fb.com kpsingh@kernel.org kafai@fb.com john.fastabend@gmail.com songliubraving@fb.com |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 1 this patch: 1 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 1 this patch: 1 |
netdev/header_inline | success | Link |
On Fri, Mar 26, 2021 at 9:05 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > permissions based on file_flags, but the returned fd ignores flags. > This means that any user can acquire a "read-write" fd for a pinned > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > because OBJ_GET by default returns a read write mapping and libbpf > doesn't expose a way to override this behaviour for programs > and links. > > Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction") > Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> > --- LGTM. Acked-by: Andrii Nakryiko <andrii@kernel.org> > kernel/bpf/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c > index 1576ff331ee4..dc56237d6960 100644 > --- a/kernel/bpf/inode.c > +++ b/kernel/bpf/inode.c > @@ -547,7 +547,7 @@ int bpf_obj_get_user(const char __user *pathname, int flags) > else if (type == BPF_TYPE_MAP) > ret = bpf_map_new_fd(raw, f_flags); > else if (type == BPF_TYPE_LINK) > - ret = bpf_link_new_fd(raw); > + ret = (f_flags != O_RDWR) ? -EINVAL : bpf_link_new_fd(raw); > else > return -ENOENT; > > -- > 2.27.0 >
On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > permissions based on file_flags, but the returned fd ignores flags. > This means that any user can acquire a "read-write" fd for a pinned > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > because OBJ_GET by default returns a read write mapping and libbpf > doesn't expose a way to override this behaviour for programs > and links. Hi Alexei and Daniel, I think these two patches might have fallen through the cracks, could you take a look? I'm not sure what the etiquette is around bumping a set, so please let me know if you'd prefer me to send the patches with acks included or something like that. Best
On Wed, Mar 31, 2021 at 7:04 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > > permissions based on file_flags, but the returned fd ignores flags. > > This means that any user can acquire a "read-write" fd for a pinned > > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > > because OBJ_GET by default returns a read write mapping and libbpf > > doesn't expose a way to override this behaviour for programs > > and links. > > Hi Alexei and Daniel, > > I think these two patches might have fallen through the cracks, could > you take a look? I'm not sure what the etiquette is around bumping a > set, so please let me know if you'd prefer me to send the patches with > acks included or something like that. It is still in patchworks. I didn't have time to think it through. Sorry for delay.
On Wed, Mar 31, 2021 at 7:04 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > > permissions based on file_flags, but the returned fd ignores flags. > > This means that any user can acquire a "read-write" fd for a pinned > > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > > because OBJ_GET by default returns a read write mapping and libbpf > > doesn't expose a way to override this behaviour for programs > > and links. > > Hi Alexei and Daniel, > > I think these two patches might have fallen through the cracks, could > you take a look? I'm not sure what the etiquette is around bumping a > set, so please let me know if you'd prefer me to send the patches with > acks included or something like that. Applied both. Thanks
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c index 1576ff331ee4..dc56237d6960 100644 --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -547,7 +547,7 @@ int bpf_obj_get_user(const char __user *pathname, int flags) else if (type == BPF_TYPE_MAP) ret = bpf_map_new_fd(raw, f_flags); else if (type == BPF_TYPE_LINK) - ret = bpf_link_new_fd(raw); + ret = (f_flags != O_RDWR) ? -EINVAL : bpf_link_new_fd(raw); else return -ENOENT;
Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access permissions based on file_flags, but the returned fd ignores flags. This means that any user can acquire a "read-write" fd for a pinned link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works because OBJ_GET by default returns a read write mapping and libbpf doesn't expose a way to override this behaviour for programs and links. Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction") Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- kernel/bpf/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)