* [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
@ 2022-02-02 6:01 Hou Tao
2022-02-02 12:26 ` Daniel Borkmann
2022-02-03 7:30 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 5+ messages in thread
From: Hou Tao @ 2022-02-02 6:01 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, houtao1,
syzbot+5ad567a418794b9b5983
After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
after mapping"), non-VM_ALLOC mappings will be marked as accessible
in __get_vm_area_node() when KASAN is enabled. But now the flag for
ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
after vmap() returns. Because the ringbuf area is created by mapping
allocated pages, so use VM_MAP instead.
After the change, info in /proc/vmallocinfo also changes from
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
Signed-off-by: Hou Tao <houtao1@huawei.com>
---
v2:
* explain why VM_ALLOC will lead to vmalloc-oob access
* add Reported-by tag
v1: https://lore.kernel.org/bpf/CANUnq3a+sT_qtO1wNQ3GnLGN7FLvSSgvit2UVgqQKRpUvs85VQ@mail.gmail.com/T/#t
---
kernel/bpf/ringbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
index 638d7fd7b375..710ba9de12ce 100644
--- a/kernel/bpf/ringbuf.c
+++ b/kernel/bpf/ringbuf.c
@@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
}
rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
- VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
+ VM_MAP | VM_USERMAP, PAGE_KERNEL);
if (rb) {
kmemleak_not_leak(pages);
rb->pages = pages;
--
2.35.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-02-02 6:01 [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf Hou Tao
@ 2022-02-02 12:26 ` Daniel Borkmann
2022-02-03 5:14 ` Hou Tao
2022-02-03 7:30 ` patchwork-bot+netdevbpf
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Borkmann @ 2022-02-02 12:26 UTC (permalink / raw)
To: Hou Tao
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, houtao1,
syzbot+5ad567a418794b9b5983, Andrey Konovalov
[ +Andrey ]
On 2/2/22 7:01 AM, Hou Tao wrote:
> After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
> after mapping"), non-VM_ALLOC mappings will be marked as accessible
> in __get_vm_area_node() when KASAN is enabled. But now the flag for
> ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
> after vmap() returns. Because the ringbuf area is created by mapping
> allocated pages, so use VM_MAP instead.
>
> After the change, info in /proc/vmallocinfo also changes from
> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> to
> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
>
> Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
> Signed-off-by: Hou Tao <houtao1@huawei.com>
> ---
> v2:
> * explain why VM_ALLOC will lead to vmalloc-oob access
Do you know which tree commit 2fd3fb0be1d1 is, looks like it's neither
in bpf nor in bpf-next tree at the moment.
Either way, I presume this fix should be routed via bpf tree rather
than bpf-next? (I can add Fixes tag while applying.)
> * add Reported-by tag
> v1: https://lore.kernel.org/bpf/CANUnq3a+sT_qtO1wNQ3GnLGN7FLvSSgvit2UVgqQKRpUvs85VQ@mail.gmail.com/T/#t
> ---
> kernel/bpf/ringbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> index 638d7fd7b375..710ba9de12ce 100644
> --- a/kernel/bpf/ringbuf.c
> +++ b/kernel/bpf/ringbuf.c
> @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> }
>
> rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> if (rb) {
> kmemleak_not_leak(pages);
> rb->pages = pages;
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-02-02 12:26 ` Daniel Borkmann
@ 2022-02-03 5:14 ` Hou Tao
2022-02-03 7:24 ` Andrii Nakryiko
0 siblings, 1 reply; 5+ messages in thread
From: Hou Tao @ 2022-02-03 5:14 UTC (permalink / raw)
To: daniel
Cc: andreyknvl, andrii, ast, bpf, davem, hotforest, houtao1,
john.fastabend, kafai, kuba, netdev, syzbot+5ad567a418794b9b5983,
yhs
Hi,
> On 2/2/22 7:01 AM, Hou Tao wrote:
> > After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
> > after mapping"), non-VM_ALLOC mappings will be marked as accessible
> > in __get_vm_area_node() when KASAN is enabled. But now the flag for
> > ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
> > after vmap() returns. Because the ringbuf area is created by mapping
> > allocated pages, so use VM_MAP instead.
> >
> > After the change, info in /proc/vmallocinfo also changes from
> > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> > to
> > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
> >
> > Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
> > Signed-off-by: Hou Tao <houtao1@huawei.com>
> > ---
> > v2:
> > * explain why VM_ALLOC will lead to vmalloc-oob access
>
> Do you know which tree commit 2fd3fb0be1d1 is, looks like it's neither
> in bpf nor in bpf-next tree at the moment.
>
It is on linux-next tree:
$ git name-rev 2fd3fb0be1d1
2fd3fb0be1d1 tags/next-20220201~2^2~96
> Either way, I presume this fix should be routed via bpf tree rather
> than bpf-next? (I can add Fixes tag while applying.)
>
Make sense and thanks for that.
Regards,
Tao
> > * add Reported-by tag
> > v1: https://lore.kernel.org/bpf/CANUnq3a+sT_qtO1wNQ3GnLGN7FLvSSgvit2UVgqQKRpUvs85VQ@mail.gmail.com/T/#t
> > ---
> > kernel/bpf/ringbuf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> > index 638d7fd7b375..710ba9de12ce 100644
> > --- a/kernel/bpf/ringbuf.c
> > +++ b/kernel/bpf/ringbuf.c
> > @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> > }
> >
> > rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> > - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> > + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> > if (rb) {
> > kmemleak_not_leak(pages);
> > rb->pages = pages;
> >
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-02-03 5:14 ` Hou Tao
@ 2022-02-03 7:24 ` Andrii Nakryiko
0 siblings, 0 replies; 5+ messages in thread
From: Andrii Nakryiko @ 2022-02-03 7:24 UTC (permalink / raw)
To: Hou Tao
Cc: Daniel Borkmann, andreyknvl, Andrii Nakryiko, Alexei Starovoitov,
bpf, David S. Miller, Hou Tao, john fastabend, Martin Lau,
Jakub Kicinski, Networking, syzbot+5ad567a418794b9b5983,
Yonghong Song
On Wed, Feb 2, 2022 at 9:14 PM Hou Tao <hotforest@gmail.com> wrote:
>
> Hi,
>
> > On 2/2/22 7:01 AM, Hou Tao wrote:
> > > After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
> > > after mapping"), non-VM_ALLOC mappings will be marked as accessible
> > > in __get_vm_area_node() when KASAN is enabled. But now the flag for
> > > ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
> > > after vmap() returns. Because the ringbuf area is created by mapping
> > > allocated pages, so use VM_MAP instead.
> > >
> > > After the change, info in /proc/vmallocinfo also changes from
> > > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> > > to
> > > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
> > >
> > > Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
> > > Signed-off-by: Hou Tao <houtao1@huawei.com>
> > > ---
> > > v2:
> > > * explain why VM_ALLOC will lead to vmalloc-oob access
> >
> > Do you know which tree commit 2fd3fb0be1d1 is, looks like it's neither
> > in bpf nor in bpf-next tree at the moment.
> >
> It is on linux-next tree:
>
> $ git name-rev 2fd3fb0be1d1
> 2fd3fb0be1d1 tags/next-20220201~2^2~96
>
> > Either way, I presume this fix should be routed via bpf tree rather
> > than bpf-next? (I can add Fixes tag while applying.)
> >
> Make sense and thanks for that.
Added
Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier
support for it")
and pushed to bpf tree, thanks.
>
> Regards,
> Tao
>
> > > * add Reported-by tag
> > > v1: https://lore.kernel.org/bpf/CANUnq3a+sT_qtO1wNQ3GnLGN7FLvSSgvit2UVgqQKRpUvs85VQ@mail.gmail.com/T/#t
> > > ---
> > > kernel/bpf/ringbuf.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> > > index 638d7fd7b375..710ba9de12ce 100644
> > > --- a/kernel/bpf/ringbuf.c
> > > +++ b/kernel/bpf/ringbuf.c
> > > @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> > > }
> > >
> > > rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> > > - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> > > + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> > > if (rb) {
> > > kmemleak_not_leak(pages);
> > > rb->pages = pages;
> > >
> >
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-02-02 6:01 [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf Hou Tao
2022-02-02 12:26 ` Daniel Borkmann
@ 2022-02-03 7:30 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2022-02-03 7:30 UTC (permalink / raw)
To: Hou Tao
Cc: daniel, ast, kafai, yhs, andrii, davem, kuba, john.fastabend,
netdev, bpf, houtao1, syzbot+5ad567a418794b9b5983
Hello:
This patch was applied to bpf/bpf.git (master)
by Andrii Nakryiko <andrii@kernel.org>:
On Wed, 2 Feb 2022 14:01:58 +0800 you wrote:
> After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
> after mapping"), non-VM_ALLOC mappings will be marked as accessible
> in __get_vm_area_node() when KASAN is enabled. But now the flag for
> ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
> after vmap() returns. Because the ringbuf area is created by mapping
> allocated pages, so use VM_MAP instead.
>
> [...]
Here is the summary with links:
- [bpf-next,v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
https://git.kernel.org/bpf/bpf/c/b293dcc473d2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-02-03 7:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-02 6:01 [PATCH bpf-next v2] bpf: use VM_MAP instead of VM_ALLOC for ringbuf Hou Tao
2022-02-02 12:26 ` Daniel Borkmann
2022-02-03 5:14 ` Hou Tao
2022-02-03 7:24 ` Andrii Nakryiko
2022-02-03 7:30 ` patchwork-bot+netdevbpf
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.