On Wed, Apr 24, 2019 at 6:09 PM Stanislav Fomichev wrote:
> target_fd is target namespace. If there is a flow dissector BPF program
> attached to that namespace, its (single) id is returned.
>
> v2:
> * don't sleep in rcu critical section (Jakub Kicinski)
> * check input prog_cnt (exit early)
>
>
On Mon, Apr 8, 2019 at 3:54 PM Daniel Borkmann wrote:
> This patch adds a new BPF_MAP_FREEZE command which allows to
> "freeze" the map globally as read-only / immutable from syscall
> side.
>
> Map permission handling has been refactored into map_get_sys_perms()
> and drops FMODE_CAN_WRITE in cas
On Tue, Mar 26, 2019 at 7:06 PM Jiong Wang wrote:
>
> In previous patch, we have split register arg type for sub-register read,
> but haven't touch read liveness.
>
> This patch further split read liveness into REG_LIVE_READ64 and
> REG_LIVE_READ32. Liveness propagation code are updated accordingl
On Tue, Mar 26, 2019 at 7:07 PM Jiong Wang wrote:
> Some code inside current implementation of "propagate_liveness" is a little
> bit verbose.
>
> This patch refactor them so the code looks more simple and more clear.
>
> The redundant usage of "vparent->frame[vstate->curframe]" is removed as we
>
On Fri, Mar 1, 2019 at 12:19 AM Daniel Borkmann wrote:
> This generic extension to BPF maps allows for directly loading an
> address residing inside a BPF map value as a single BPF ldimm64
> instruction.
[...]
> @@ -6698,16 +6705,44 @@ static int replace_map_fd_with_map_ptr(struct
> bpf_verifier_
On Fri, Feb 22, 2019 at 11:51 PM Alexei Starovoitov
wrote:
>
> On Fri, Feb 22, 2019 at 01:59:10PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 22, 2019 at 1:38 PM David Miller wrote:
> > >
> > > Don't be surprised if we see more separation like this in the future too.
> >
> > Yes, with the whole
On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
> > On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
> >
> >> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
> >>
> >> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> >>>> On Feb 22, 201
On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> > On Feb 22, 2019, at 1:43 PM, Jann Horn wrote:
> >
> > (adding some people from the text_poke series to the thread, removing
> > stable@)
> >
> > On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski wrote
(adding some people from the text_poke series to the thread, removing stable@)
On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski wrote:
> > On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov
> > wrote:
> >> On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
> >> On Fri, 22 Feb 2019 11:
The listed address for the CAIF maintainer bounces with
"553 5.3.0 ... No such user here", and the
only existing email address of the maintainer in git history hasn't
responded in a week.
Therefore, remove the listed maintainer and mark CAIF as orphan.
Signed-off-by: Jann Horn
-
On Thu, Feb 21, 2019 at 9:53 AM Daniel Borkmann wrote:
> On 02/21/2019 06:31 AM, Kees Cook wrote:
> > On Wed, Feb 20, 2019 at 8:03 PM Alexei Starovoitov
> > wrote:
> >>
> >> On Wed, Feb 20, 2019 at 3:59 PM Alexei Starovoitov
> >> wrote:
> >>>
> >>> On Thu, Feb 21, 2019 at 12:01:35AM +0100, Danie
__sys_setsockopt() already checks for `optlen < 0`. Add an equivalent check
to the compat path for robustness. This has to be `> INT_MAX` instead of
`< 0` because the signedness of `optlen` is different here.
Signed-off-by: Jann Horn
---
net/compat.c | 6 +-
1 file changed, 5 i
On Fri, Feb 15, 2019 at 7:35 PM Alexander Duyck
wrote:
> On Fri, Feb 15, 2019 at 6:10 AM Jann Horn wrote:
> > On Thu, Feb 14, 2019 at 11:21 PM David Miller wrote:
> > > From: Jann Horn
> > > Date: Thu, 14 Feb 2019 22:26:22 +0100
> > >
> > > &
Replace an open-coded version of skb_put_zero() with a call to the helper.
This is a cleanup and is also useful for potentially adding KASAN
integration to SKBs in the future.
Signed-off-by: Jann Horn
---
drivers/staging/unisys/visornic/visornic_main.c | 4 +---
1 file changed, 1 insertion
On Thu, Feb 14, 2019 at 11:21 PM David Miller wrote:
>
> From: Jann Horn
> Date: Thu, 14 Feb 2019 22:26:22 +0100
>
> > On Thu, Feb 14, 2019 at 6:13 PM David Miller wrote:
> >>
> >> From: Jann Horn
> >> Date: Wed, 13 Feb 2019 22:45:59 +0100
> &
On Thu, Feb 14, 2019 at 10:35 PM Jann Horn wrote:
> Use existing skb_put_data() and skb_trim() instead of open-coding them,
> with the skb_put_data() first so that logically, `skb` still contains the
> data to be copied in its data..tail area when skb_put_data() reads it.
> This chang
future integration of skbuffs with things like KASAN.
Signed-off-by: Jann Horn
---
net/caif/cfpkt_skbuff.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index 38c2b7a890dd..37ac5ca0ffdf 100644
--- a/net/caif
On Thu, Feb 14, 2019 at 6:13 PM David Miller wrote:
>
> From: Jann Horn
> Date: Wed, 13 Feb 2019 22:45:59 +0100
>
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath lat
a `WARN_ON(page_ref_count(page) == 0)` in the
`offset < 0` path, below the virt_to_page() call, and then repeatedly call
writev() on a TAP device with IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Signed-off-by: Jann Horn
---
sending t
On Wed, Feb 13, 2019 at 11:42 PM Alexander Duyck
wrote:
> On Wed, Feb 13, 2019 at 12:42 PM Jann Horn wrote:
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath later,
> > the
th IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Signed-off-by: Jann Horn
---
Resending to davem at the request of akpm.
mm/page_alloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.
On Wed, Feb 13, 2019 at 9:59 PM Andrew Morton wrote:
>
> On Wed, 13 Feb 2019 21:41:57 +0100 Jann Horn wrote:
>
> > The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> > number of references that we might need to create in the fastpath later,
> >
th IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI,
with a vector consisting of 15 elements containing 1 byte each.
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
mm/page_alloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 35fdde
On Sat, Jan 26, 2019 at 1:43 AM Jann Horn wrote:
> On Sat, Jan 26, 2019 at 12:44 AM Alexei Starovoitov
> wrote:
> >
> > On Fri, Jan 25, 2019 at 02:51:12PM -0800, Paul E. McKenney wrote:
> > > > >
> > > > > So no more than (say) 100 milliseconds?
On Sat, Jan 26, 2019 at 12:44 AM Alexei Starovoitov
wrote:
>
> On Fri, Jan 25, 2019 at 02:51:12PM -0800, Paul E. McKenney wrote:
> > > >
> > > > So no more than (say) 100 milliseconds?
> > >
> > > Depends on RLIMIT_MEMLOCK and on how hard userspace is trying to make
> > > things slow, I guess - if
On Fri, Jan 25, 2019 at 5:12 AM Paul E. McKenney wrote:
> On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> > On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> > wrote:
> > > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > >
On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney wrote:
> On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Jan 24, 2019 at
On Fri, Jan 25, 2019 at 12:59 AM Alexei Starovoitov
wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > Thanks for having kernel/locking people on Cc...
> >
> > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> >
> > > Implementation details:
> > > - on
On Wed, Jan 23, 2019 at 6:04 PM Greg Kroah-Hartman
wrote:
> On Tue, Jan 22, 2019 at 03:36:54PM +0100, Jann Horn wrote:
> > On Thu, Jan 3, 2019 at 1:08 AM Alexei Starovoitov
> > wrote:
> > > On Thu, Jan 03, 2019 at 12:58:26AM +0100, Daniel Borkmann wrote:
> > >
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
On Thu, Jan 3, 2019 at 1:08 AM Alexei Starovoitov
wrote:
> On Thu, Jan 03, 2019 at 12:58:26AM +0100, Daniel Borkmann wrote:
> > This set fixes an out of bounds case under speculative execution
> > by implementing masking of pointer alu into the verifier. For
> > details please see the individual p
Hi!
Sorry about the extremely slow reply, I was on vacation over the
holidays and only got back today.
On Thu, Jan 3, 2019 at 12:58 AM Daniel Borkmann wrote:
> Jann reported that the original commit back in b2157399cc98
> ("bpf: prevent out-of-bounds speculation") was not sufficient
> to stop CP
On Fri, Oct 5, 2018 at 4:27 PM Lorenz Bauer wrote:
>
> On Mon, 1 Oct 2018 at 20:12, Daniel Borkmann wrote:
> >
> > On 10/01/2018 12:45 PM, Lorenz Bauer wrote:
> > > This patch set adds a new flag BPF_F_ZERO_SEED, which allows
> > > forcing the seed used by hash maps to zero. This makes
> > > it p
On Fri, Oct 5, 2018 at 4:21 PM Lorenz Bauer wrote:
> On Fri, 5 Oct 2018 at 15:12, Jann Horn wrote:
> > On Fri, Oct 5, 2018 at 9:42 AM Lorenz Bauer wrote:
> > > On Tue, 2 Oct 2018 at 21:00, Jann Horn wrote:
> > > > If this is for testing only, you can slap a capabl
On Fri, Oct 5, 2018 at 9:42 AM Lorenz Bauer wrote:
> On Tue, 2 Oct 2018 at 21:00, Jann Horn wrote:
> >
> > If this is for testing only, you can slap a capable(CAP_SYS_ADMIN)
> > check in here, right? I doubt it matters, but I don't really like
> > seein
On Mon, Oct 1, 2018 at 12:47 PM Lorenz Bauer wrote:
>
> Add a new flag BPF_F_ZERO_SEED, which forces a hash map
> to initialize the seed to zero.
> ---
> include/uapi/linux/bpf.h | 2 ++
> kernel/bpf/hashtab.c | 8 ++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/i
Hi!
Per the policy at Documentation/networking/netdev-FAQ.rst, I'm sending
this to netdev@ and davem, rather than stable@; with a CC to security@
because I believe that this is a security process issue.
Upstream commit dd066823db2ac4e22f721ec85190817b58059a54
("bpf/verifier: disallow pointer subt
On Tue, Jul 31, 2018 at 7:54 AM Florian Westphal wrote:
>
> Eric Dumazet wrote:
> > We currently check current frags memory usage only when
> > a new frag queue is created. This allows attackers to first
> > consume the memory budget (default : 4 MB) creating thousands
> > of frag queues, then se
On Thu, May 3, 2018 at 12:36 AM, Alexei Starovoitov wrote:
> Introduce helper:
> int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
> struct umh_info {
>struct file *pipe_to_umh;
>struct file *pipe_from_umh;
>pid_t pid;
> };
>
> that GPLed kernel modules
Remove dead code that bails on `attr->value_size > KMALLOC_MAX_SIZE` - the
previous check already bails on `attr->value_size != 4`.
Signed-off-by: Jann Horn
---
kernel/bpf/sockmap.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockma
, &syn_packet.tcp);
while (1) {
int write_res = write(tun_fd, &syn_packet, sizeof(syn_packet));
if (write_res != sizeof(syn_packet))
err(1, "packet write failed");
}
}
Fixes: cfb6eeb4c860 ("[TCP]: MD5 Signature O
[resend as plaintext, apparently mobile gmail will send HTML mails]
On Thu, Feb 22, 2018 at 3:20 AM, Alexei Starovoitov
wrote:
> On Wed, Feb 21, 2018 at 01:13:03PM +0100, Florian Westphal wrote:
>>
>> Obvious candidates are: meta, numgen, limit, objref, quota, reject.
>>
>> We should probably als
On Sat, Dec 23, 2017 at 3:07 AM, Alexei Starovoitov
wrote:
> On Sat, Dec 23, 2017 at 02:38:29AM +0100, Jann Horn wrote:
>> On Fri, Dec 22, 2017 at 10:33 PM, Alexei Starovoitov wrote:
>> > instead of computing max stack depth for current call chain only
>> > track the m
mpute max total.
>
> Fixes: f4d7e40a5b71 ("bpf: introduce function calls (verification)")
> Reported-by: Jann Horn
> Signed-off-by: Alexei Starovoitov
Does this work in cases where multiple invocations of a function have
different stack access patterns because their inputs have
On Fri, Dec 22, 2017 at 4:37 AM, Alexei Starovoitov
wrote:
> On Fri, Dec 22, 2017 at 02:14:45AM +0100, Jann Horn wrote:
>> Hi!
>>
>> I saw the recently-added support for multiple functions in a single
>> program in BPF. I've stumbled over something that looks like
ret
Signed-off-by: Jann Horn
---
tools/testing/selftests/bpf/test_verifier.c | 34 +
1 file changed, 34 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_verifier.c
b/tools/testing/selftests/bpf/test_verifier.c
index 3bacff0d6f91..71fb0be81b78 100644
--- a
Hi!
I saw the recently-added support for multiple functions in a single
program in BPF. I've stumbled over something that looks like it might
be a bug; I haven't verified it yet, but I thought I should give you a
heads-up before this lands in a release in case I'm right. If I'm
wrong, it might be
lues")
> Reported-by: Jann Horn
> Signed-off-by: Edward Cree
> ---
> kernel/bpf/verifier.c | 30 --
> 1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d4593571c404..5be
On Mon, Dec 4, 2017 at 6:03 PM, Jann Horn wrote:
> As far as I can tell, commit b03c9f9fdc37 ("bpf/verifier: track signed
> and unsigned min/max values") introduced the following effectless bug
> in the BPF_RSH case of adjust_scalar_min_max_vals() (unless t
As far as I can tell, commit b03c9f9fdc37 ("bpf/verifier: track signed
and unsigned min/max values") introduced the following effectless bug
in the BPF_RSH case of adjust_scalar_min_max_vals() (unless that's
intentional):
`dst_reg->smax_value` is only updated in the case where
`dst_reg->smin_value
On Fri, Dec 1, 2017 at 5:04 AM, Willem de Bruijn
wrote:
> On Thu, Nov 30, 2017 at 7:46 PM, Jann Horn wrote:
>> Check whether inputs from userspace are too long (explicit length field too
>> big or string not null-terminated) to avoid out-of-bounds reads.
>>
>> As far
match")
Signed-off-by: Jann Horn
---
net/netfilter/xt_bpf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/xt_bpf.c b/net/netfilter/xt_bpf.c
index 041da0d9c06f..1f7fbd3c7e5a 100644
--- a/net/netfilter/xt_bpf.c
+++ b/net/netfilter/xt_bpf.c
@@ -27,6 +27,9 @@
On Mon, May 8, 2017 at 12:51 AM, Daniel Borkmann wrote:
> On 05/08/2017 12:26 AM, Jann Horn wrote:
>>
>> On Mon, May 8, 2017 at 12:04 AM, Daniel Borkmann
>> wrote:
>>>
>>> The patch fixes two things at once:
>>>
>>> 1) It checks th
: verifier (add ability to receive verification
> log)")
> Reported-by: Jann Horn
> Signed-off-by: Daniel Borkmann
[...]
> @@ -362,9 +363,19 @@ static void print_bpf_insn(struct bpf_insn *insn)
> insn->code,
>
On Wed, Nov 16, 2016 at 9:25 PM, Josef Bacik wrote:
> On 11/16/2016 01:41 PM, Jann Horn wrote:
>>
>> On Tue, Nov 15, 2016 at 3:20 PM, Josef Bacik wrote:
>>>
>>> On 11/15/2016 08:47 AM, Jann Horn wrote:
>>>>
>>>> In states_equal(
On Tue, Nov 15, 2016 at 3:20 PM, Josef Bacik wrote:
> On 11/15/2016 08:47 AM, Jann Horn wrote:
>> In states_equal():
>> if (rold->type == NOT_INIT ||
>>(rold->type == UNKNOWN_VALUE && rcur->type != NOT_INIT))
>> <
>> co
ND's.
>>
>> 3) Don't do operations on the ranges if they are set to the limits, as they
>> are
>> by definition undefined, and allowing arithmetic operations on those values
>> could make them appear valid when they really aren't.
>>
>> This
't.
>
> This fixes the testcase provided by Jann as well as a few other theoretical
> problems.
>
> Reported-by: Jann Horn
> Signed-off-by: Josef Bacik
A nit: check_mem_access() still has an explicit cast of reg->min_value to s64, I
think that's not necessary anymore?
Can you resend with "git send-email" or so? "git am" says that the
patch is corrupt, likely because of line wrapping.
On Wed, Nov 9, 2016 at 10:21 PM, Josef Bacik wrote:
> On 11/08/2016 07:23 PM, Jann Horn wrote:
>>
>> In 484611357c19 (not in any s
In 484611357c19 (not in any stable kernel yet), functionality is
introduced that allows root (and afaics nobody else, since nobody else
is allowed to perform pointer arithmetic) to basically write to (and
read from) arbitrary kernel memory. There are multiple bugs in the
validation logic:
- A bit
On Wed, Oct 26, 2016 at 10:03:09PM +0200, Mickaël Salaün wrote:
> On 26/10/2016 21:01, Jann Horn wrote:
> > On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote:
> >> This new arraymap looks like a set and brings new properties:
> >> * strong typing of entries:
On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote:
> This new arraymap looks like a set and brings new properties:
> * strong typing of entries: the eBPF functions get the array type of
> elements instead of CONST_PTR_TO_MAP (e.g.
> CONST_PTR_TO_LANDLOCK_HANDLE_FS);
> * force seque
On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
> The loaded Landlock eBPF programs can be triggered by a seccomp filter
> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed
> from
> a seccomp filter to eBPF programs. This allow flexible security policies
>
On Thu, Oct 20, 2016 at 02:37:47PM -0400, David Miller wrote:
> From: Pablo Neira Ayuso
> Date: Thu, 20 Oct 2016 20:22:24 +0200
>
> > On Sat, Sep 24, 2016 at 12:21:04AM +0200, Jann Horn wrote:
> >> This prevents the modification of nf_conntrack_max in unprivileged netw
This prevents the modification of nf_conntrack_max in unprivileged network
namespaces. For unprivileged network namespaces, ip_conntrack_max is kept
as a readonly sysctl in order to minimize potential compatibility issues.
This patch should apply cleanly to the net tree.
Signed-off-by: Jann Horn
t I believe that this solution is slightly less error-prone.
If you think I should switch to the simple fix, let me know.
Signed-off-by: Jann Horn
---
include/linux/sysctl.h | 1 +
net/ax25/sysctl_net_ax25.c | 4 +++-
net/ieee802154/6lowpan/reassembly.
ot;NONE";
if (write(stolen_fd, data, strlen(data)) != strlen(data))
err(1, "write");
return 0;
}
Repro:
$ gcc -Wall -o attack attack.c -std=gnu99
$ cat /proc/sys/net/netfilter/nf_log/2
nf_log_ipv4
$ ./attack
$ cat /proc/sys/net/netfilter/nf_log/2
NONE
On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote:
> Add eBPF functions to compare file system access with a Landlock file
> system handle:
> * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file)
> This function allows to compare the dentry, inode, device or mount
>
on commit a43eec304259 ("bpf: introduce bpf_perf_event_output()
> helper") adjusted
> the logic and inadvertently broke it.
> Get rid of the clever bool compare and go back to two-way check
> from map and from helper perspective.
>
> Fixes: a43eec304259 ("bpf: introd
IMM64 insn"), but is only
exploitable since
commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
previously, CAP_SYS_ADMIN was required to reach the vulnerable code.
(posted publicly according to request by maintainer)
Signed-off-by: Jann Horn
Signed-off-by: Linus T
70 matches
Mail list logo
