There's no reason to perform a buffer copy for the firmware name. This
also avoids a (currently impossible with current callers) NULL dereference
if there was no matching firmware.
Signed-off-by: Kees Cook keesc...@chromium.org
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 12
nt this because of fear of bugs or because
>> it's actually needed. I think the design of all CAP_* is to give
>> unprivileged users permissions to do something beyond normal that
>> can potentially be harmful for other users or the whole system.
>> In this case it's
(tests); i++) {
> struct bpf_insn *prog = tests[i].insns;
> int prog_type = tests[i].prog_type;
> int prog_len = probe_filter_length(prog);
> int *fixup = tests[i].fixup;
> - int map_fd = -1;
> +
On Wed, Oct 7, 2015 at 4:49 PM, Alexei Starovoitov <a...@plumgrid.com> wrote:
> On 10/7/15 3:22 PM, Kees Cook wrote:
>>>
>>> Yes, I agree with you that there would be a CVE regardless. I still
>>> >like the option of configurable access, not a big fan of the
feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
> This toggle defaults to off (0), but can be set true (1). Once true,
> bpf programs and maps cannot be accessed from unprivileged process,
> and the toggle cannot be set back to false.
>
> Signed-off-by: Alexei Starovoit
BPF_STX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, 0),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + },
> + .errstr_unpriv = "R1 leaks addr",
> + .result_unpriv = REJECT,
> + .errstr = "invalid bpf_context access",
> + .result = REJECT,
> + },
> + {
> + "unpriv: write pointer into map elem value",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
> + BPF_STX_MEM(BPF_DW, BPF_REG_0, BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + },
> + .fixup = {3},
> + .errstr_unpriv = "R0 leaks addr",
> + .result_unpriv = REJECT,
> + .result = ACCEPT,
> + },
> + {
> + "unpriv: partial copy of pointer",
> + .insns = {
> + BPF_MOV32_REG(BPF_REG_1, BPF_REG_10),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + },
> + .errstr_unpriv = "R10 partial copy",
> + .result_unpriv = REJECT,
> + .result = ACCEPT,
> + },
> };
>
> static int probe_filter_length(struct bpf_insn *fp)
> @@ -910,12 +1130,15 @@ static int create_map(void)
> static int test(void)
> {
> int prog_fd, i, pass_cnt = 0, err_cnt = 0;
> + bool unpriv = geteuid() != 0;
>
> for (i = 0; i < ARRAY_SIZE(tests); i++) {
> struct bpf_insn *prog = tests[i].insns;
> int prog_type = tests[i].prog_type;
> int prog_len = probe_filter_length(prog);
> int *fixup = tests[i].fixup;
> + int expected_result;
> + const char *expected_errstr;
> int map_fd = -1;
>
> if (*fixup) {
> @@ -932,7 +1155,17 @@ static int test(void)
> prog, prog_len * sizeof(struct
> bpf_insn),
> "GPL", 0);
>
> - if (tests[i].result == ACCEPT) {
> + if (unpriv && tests[i].result_unpriv != UNDEF)
> + expected_result = tests[i].result_unpriv;
> + else
> + expected_result = tests[i].result;
> +
> + if (unpriv && tests[i].errstr_unpriv)
> + expected_errstr = tests[i].errstr_unpriv;
> + else
> + expected_errstr = tests[i].errstr;
> +
> + if (expected_result == ACCEPT) {
> if (prog_fd < 0) {
> printf("FAIL\nfailed to load prog '%s'\n",
>strerror(errno));
> @@ -947,7 +1180,7 @@ static int test(void)
> err_cnt++;
> goto fail;
> }
> - if (strstr(bpf_log_buf, tests[i].errstr) == 0) {
> + if (strstr(bpf_log_buf, expected_errstr) == 0) {
> printf("FAIL\nunexpected error message: %s",
>bpf_log_buf);
> err_cnt++;
> --
> 1.7.9.5
>
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uldn't the "unique ID" be the fd itself? I imagine KCMP_FILE could
be used, for example.
-Kees
> userspace can detect when two seccomp filters were inherited from each
> other and clone the filter tree accordingly.
>
> Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com
", otherwise we could
run into races as the ptracee adds filters. i.e. it is not safe to
examine seccomp filters from tasks other than current.
-Kees
>
> Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com>
> CC: Kees Cook <keesc...@chromium.org>
> CC: Will Drew
d not what's pointed
to, so you may be out of luck there too. Sorry! On the TODO list is
doing deep argument inspection, but it is not an easy thing to get
right. :)
-Kees
>
> Thanks everyone for the clarification!
>
> On Fri, Sep 4, 2015 at 4:01 AM, Kees Cook <keesc...@chromium.or
s, to this limited feature set is ok
> for now.
>
> Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com>
> CC: Kees Cook <keesc...@chromium.org>
> CC: Will Drewry <w...@chromium.org>
> CC: Oleg Nesterov <o...@redhat.com>
> CC: Andy Lutomirski <
On Fri, Sep 4, 2015 at 2:06 PM, Tycho Andersen
<tycho.ander...@canonical.com> wrote:
> On Fri, Sep 04, 2015 at 01:34:12PM -0700, Kees Cook wrote:
>> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
>> <tycho.ander...@canonical.com> wrote:
>> >
>
> Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com>
> CC: Kees Cook <keesc...@chromium.org>
> CC: Will Drewry <w...@chromium.org>
> CC: Oleg Nesterov <o...@redhat.com>
> CC: Andy Lutomirski <l...@amacapital.net>
> CC: Pavel Emelyano
On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen
<tycho.ander...@canonical.com> wrote:
> On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote:
>> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
>> <tycho.ander...@canonical.com> wrote:
>> > This com
On Tue, Sep 8, 2015 at 6:40 AM, Tycho Andersen
<tycho.ander...@canonical.com> wrote:
> On Sat, Sep 05, 2015 at 09:13:02AM +0200, Michael Kerrisk (man-pages) wrote:
>> On 09/04/2015 10:41 PM, Kees Cook wrote:
>> > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
>> &
inished pondering, so I
don't think those features will be added soon.
-Kees
[1]
http://man7.org/conf/lpc2015/limiting_kernel_attack_surface_with_seccomp-LPC_2015-Kerrisk.pdf
[2] see subdirectory "minijail" after "git clone
https://chromium.googlesource.com/chromiumos/platform
SYNCs to merge detected sibling
threads, since merging things that weren't merged before creates no
problems.
This means the parenting logic is heuristic, but it's entirely in
userspace, so the complexity burden doesn't live in seccomp which we,
by design, want to keep as simple as possible.
-Ke
On Fri, Oct 2, 2015 at 2:29 PM, Andy Lutomirski <l...@amacapital.net> wrote:
> On Fri, Oct 2, 2015 at 2:10 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen
>> <tycho.ander...@canonical.com> wrote:
>>> Hi all,
&
On Fri, Oct 2, 2015 at 3:04 PM, Andy Lutomirski <l...@amacapital.net> wrote:
> On Fri, Oct 2, 2015 at 3:02 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Fri, Oct 2, 2015 at 2:29 PM, Andy Lutomirski <l...@amacapital.net> wrote:
>>> On Fri, Oct
On Fri, Oct 2, 2015 at 3:57 PM, Daniel Borkmann <dan...@iogearbox.net> wrote:
> On 10/03/2015 12:44 AM, Tycho Andersen wrote:
>>
>> On Fri, Oct 02, 2015 at 02:10:24PM -0700, Kees Cook wrote:
>
> ...
>>
>> Ok, how about,
>>
>> struct so
On Wed, Sep 9, 2015 at 9:52 AM, Alexei Starovoitov
<alexei.starovoi...@gmail.com> wrote:
> On Wed, Sep 09, 2015 at 09:37:51AM -0700, Kees Cook wrote:
>> On Wed, Sep 9, 2015 at 9:09 AM, Daniel Borkmann <dan...@iogearbox.net> wrote:
>> > On 09/09/2015 06:0
gt;
> Yep, +1.
Hrmpf. This adds to the cognitive load for accepting this patch
series. :P Now I have to convince myself that there is no additional
exposure to seccomp by using the entire set of eBPF instructions.
While I'm pretty sure it'll be fine, I really don't want to risk being
wrong and o
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov <a...@plumgrid.com> wrote:
> On 10/5/15 2:00 PM, Kees Cook wrote:
>>
>> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov<a...@plumgrid.com>
>> wrote:
>>>
>>> >In order to let unprivileged us
ointed out.
Sorry if I missed it: this this happen yet?
-Kees
--
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nd the actual information is lost. This affects the isdnlog
> userspace program which stopped logging information since that commit.
Oh, that's weird, but yeah, these calls aren't expanding format
strings, so I'm fine with this change.
Acked-by: Kees Cook <keesc...@chromium.org>
On the other
t's meaningless, then yeah, that seems like
a reasonable change. Can you send a patch? (Also, if it's legacy code,
maybe it could be turned off entirely, not just for containers?)
-Kees
--
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubs
Create the kstrtobool_from_user helper and moves strtobool logic into
the new kstrtobool (matching all the other kstrto* functions). Provides
an inline wrapper for existing strtobool callers.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/kernel.h | 3 +++
include
This changes several users of manual "on"/"off" parsing to use strtobool.
(Which means they will now parse y/n/1/0 meaningfully too.)
Signed-off-by: Kees Cook <keesc...@chromium.org>
Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com>
Acked-by: Michael Elle
Add support for "on" and "off" when converting to boolean.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
lib/kstrtox.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lib/kstrtox.c b/lib/kstrtox.c
index e18f088704d7..09e83a19a96d 100644
---
Some callers of strtobool were passing a pointer to unterminated strings.
In preparation of adding multi-character processing to kstrtobool, update
the callers to not pass single-character pointers, and switch to using the
new kstrtobool_from_user helper where possible.
Signed-off-by: Kees Cook
On Thu, Feb 4, 2016 at 2:43 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 11:00 PM, Kees Cook <keesc...@chromium.org> wrote:
>> Create the kstrtobool_from_user helper and moves strtobool logic into
>> the new kstrtobool (matching all
This consolidates logic for handling "on"/"off" parsing for bools into
the strtobool function, by way of moving it into kstrtobool (with helpers),
and updating various callers.
arch/powerpc/kernel/rtasd.c|9 ---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 10
On Thu, Feb 4, 2016 at 2:59 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 11:00 PM, Kees Cook <keesc...@chromium.org> wrote:
>> Some callers of strtobool were passing a pointer to unterminated strings.
>> In preparation of adding
On Thu, Feb 4, 2016 at 3:00 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 11:00 PM, Kees Cook <keesc...@chromium.org> wrote:
>> Add support for "on" and "off" when converting to boolean.
>>
>> Signed-off
On Thu, Feb 4, 2016 at 4:11 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
>> On Thu, Feb 4, 2016 at 11:00 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> This changes sev
On Thu, Feb 4, 2016 at 3:04 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 11:00 PM, Kees Cook <keesc...@chromium.org> wrote:
>> This changes several users of manual "on"/"off" parsing to use strtobool.
>> (Which mea
On Thu, Feb 4, 2016 at 3:55 PM, Rasmus Villemoes
<li...@rasmusvillemoes.dk> wrote:
> On Thu, Feb 04 2016, Kees Cook <keesc...@chromium.org> wrote:
>
>> Create the kstrtobool_from_user helper and moves strtobool logic into
>> the new kstrtobool (matching all the othe
Create the kstrtobool_from_user helper and moves strtobool logic into
the new kstrtobool (matching all the other kstrto* functions). Provides
an inline wrapper for existing strtobool callers.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v3:
- drop needless "base"
This changes several users of manual "on"/"off" parsing to use strtobool.
Some side-effects:
- these uses will now parse y/n/1/0 meaningfully too
- the early_param uses will now bubble up parse errors
Signed-off-by: Kees Cook <keesc...@chromium.org>
Acked-by: H
Some callers of strtobool were passing a pointer to unterminated strings.
In preparation of adding multi-character processing to kstrtobool, update
the callers to not pass single-character pointers, and switch to using the
new kstrtobool_from_user helper where possible.
Signed-off-by: Kees Cook
This consolidates logic for handling "on"/"off" parsing for bools into the
strtobool function, by way of moving it into kstrtobool (with helpers),
and updating various callers.
v3:
- removed unused "base" argument
- fixed missing description change
- retained inverted __setup return values
-
Add support for "on" and "off" when converting to boolean.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v3:
- add dropped descripion change, andy.shevchenko
---
lib/kstrtox.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff -
On Fri, Feb 5, 2016 at 2:46 AM, David Laight <david.lai...@aculab.com> wrote:
> From: Kees Cook
>> Sent: 04 February 2016 21:01
>> Some callers of strtobool were passing a pointer to unterminated strings.
>> In preparation of adding multi-character processing to kstrto
On Mon, Feb 1, 2016 at 5:17 AM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, Jan 28, 2016 at 4:17 PM, Kees Cook <keesc...@chromium.org> wrote:
>> Some callers of strtobool were passing a pointer to unterminated strings.
>> This fixes the issue and cons
Some callers of strtobool were passing a pointer to unterminated strings.
This fixes the issue and consolidates some logic in cifs.
Signed-off-by: Kees Cook <keesc...@chromium.org>
Cc: Amitkumar Karwar <akar...@marvell.com>
Cc: Nishant Sarmukadam <nisha...@marvell.com>
On Wed, Jan 27, 2016 at 4:58 PM, Joe Perches <j...@perches.com> wrote:
> On Wed, 2016-01-27 at 16:45 -0800, Kees Cook wrote:
>> Some callers of strtobool were passing a pointer to unterminated strings.
>> This fixes the issue and consolidates some logic in cifs.
>
Some callers of strtobool were passing a pointer to unterminated strings.
This fixes the issue and consolidates some logic in cifs.
Signed-off-by: Kees Cook <keesc...@chromium.org>
Cc: Amitkumar Karwar <akar...@marvell.com>
Cc: Nishant Sarmukadam <nisha...@marvell.com>
Several places in the kernel expect to use "on" and "off" for their
boolean signifiers, so add them to strtobool.
Signed-off-by: Kees Cook <keesc...@chromium.org>
Cc: Rasmus Villemoes <li...@rasmusvillemoes.dk>
Cc: Daniel Borkmann <dan...@io
This consolidates logic for handling "on"/"off" parsing for bools into
the existing strtobool function. This requires making sure callers are
passing NULL-terminated strings.
-Kees
This changes several users of manual "on"/"off" parsing to use strtobool.
Signed-off-by: Kees Cook <keesc...@chromium.org>
Cc: x...@kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
---
arch/powerpc/kernel/rtasd.c | 10 +++-
On Tue, Jul 26, 2016 at 10:29 AM, Michael Kerrisk (man-pages)
<mtk.manpa...@gmail.com> wrote:
> On 26 July 2016 at 18:52, Kees Cook <keesc...@chromium.org> wrote:
>> On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
>> <ebied...@xmission.com> wrote:
>>>
don't see how this helps the case of "let
user foobar open 1 userns, but everyone else is 0", which is likely
the middle ground between "just turn it off" and "everyone gets to
create usernamespaces". I'm personally not interested in that level of
granularity, but in earlier discussions it sounded like this was
something you wanted?
-Kees
--
Kees Cook
Chrome OS & Brillo Security
or anything
> like that and you know you won't be needing a kernel feature having an
> easy way to disable the feature is useful for making the kernel
> marginally more secure, as certain attack vectors are no longer
> possible.
-Kees
--
Kees Cook
Chrome OS & Brillo Security
ons(+), 37 deletions(-)
> create mode 100644 include/linux/checmate.h
> create mode 100644 include/uapi/linux/checmate.h
> create mode 100644 samples/bpf/checmate1_kern.c
> create mode 100644 samples/bpf/checmate1_user.c
> create mode 100644 security/checmate/Kconfig
> create mode 100644 security/checmate/Makefile
> create mode 100644 security/checmate/checmate_bpf.c
> create mode 100644 security/checmate/checmate_lsm.c
>
> --
> 2.7.4
>
--
Kees Cook
Nexus Security
On Mon, Aug 8, 2016 at 5:00 PM, Sargun Dhillon <sar...@sargun.me> wrote:
> On Mon, Aug 08, 2016 at 04:44:02PM -0700, Kees Cook wrote:
>> On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon <sar...@sargun.me> wrote:
>> > I distributed this patchset to linux-security-mod...
On Wed, Feb 1, 2017 at 5:01 AM, Shubham Bansal
<illusionist@gmail.com> wrote:
> Hi Kees & Daniel,
>
> On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
>> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
>> >&g
my current mapping good enough to make the JIT fast enough ?
> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> its instructions with native instructions.
I don't know -- it might be tricky with needing to deal with 64-bit
registers. But if you can make it faster than the non-JIT, it should
be a win. :) Yay assembly.
-Kees
--
Kees Cook
Pixel Security
use
> they are more conservative.
>
> Changes since v1
> - add kvmalloc_array - this might silently fix some overflow issues
> because most users simply didn't check the overflow for the vmalloc
> fallback.
Awesome, thanks for adding that API. :)
Acked-by: Kees Cook <keesc...@chromium.org>
-Kees
--
Kees Cook
Nexus Security
it is a generic issue, then CONFIG_HARDENED_USERCOPY_PAGESPAN looks
> considerably broken as there are tons of copies onto stack. I don't
> see what's special in this particular case.
There have been so many false positives on this option, even though it
is known not to be quite right, that I'll probably just remove it
entirely. It clearly needs much more work before it'll be useful, so
there's no reason to leave it in the kernel to confuse people. :)
-Kees
--
Kees Cook
Nexus Security
On Wed, Oct 5, 2016 at 1:58 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
>
> On 04/10/2016 01:43, Kees Cook wrote:
>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün <m...@digikod.net> wrote:
>>> This allows to add new eBPF programs to Landlock ho
ber of grammar issues that slow me
down when reading this, so when it does move into Documentation/, I'll
have some English nit-picks. :)
While reading I found myself wanting an explicit list of "guiding
principles" for anyone implementing new hooks. It is touched on in
several places (don't expose things, don't allow for privilege
changes, etc). Having that spelled out somewhere would be nice.
-Kees
--
Kees Cook
Nexus Security
mirski <l...@amacapital.net>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: James Morris <james.l.mor...@oracle.com>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Serge E. Hallyn <se...@hallyn.com>
of handles replace custom checker groups
> * simpler userland API
>
> Signed-off-by: Mickaël Salaün <m...@digikod.net>
> Cc: Alexei Starovoitov <a...@kernel.org>
> Cc: Andy Lutomirski <l...@amacapital.net>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc:
Borkmann <dan...@iogearbox.net>
> Cc: Daniel Mack <dan...@zonque.org>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Tejun Heo <t...@kernel.org>
> Link: https://lkml.kernel.org/r/20160826021432.ga8...@ast-m
@digikod.net>
>>>> Cc: Alexei Starovoitov <a...@kernel.org>
>>>> Cc: Andy Lutomirski <l...@amacapital.net>
>>>> Cc: Daniel Borkmann <dan...@iogearbox.net>
>>>> Cc: Kees Cook <keesc...@chromium.org>
>>>> ---
>&
trigger
landlock, it may be best to just leave the low 16 bits unused
entirely. Then all state management is handled by the landlock eBPF
maps, not a value coming from seccomp that can get stomped on by new
filters, etc.
-Kees
--
Kees Cook
Nexus Security
From: Emese Revfy <re.em...@gmail.com>
The coming initify gcc plugin expects const pointer types, and caught
some __printf arguments that weren't const yet. This fixes those.
Signed-off-by: Emese Revfy <re.em...@gmail.com>
[kees: expanded commit message]
Signed-off-by: Kees
On Sat, Dec 17, 2016 at 8:57 AM, David Miller <da...@davemloft.net> wrote:
> From: Kees Cook <keesc...@chromium.org>
> Date: Fri, 16 Dec 2016 16:58:58 -0800
>
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using de
e more conservative.
>
> Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
> Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
> Cc: Anton Vorontsov <an...@enomsg.org>
> Cc: Colin Cross <ccr...@android.com>
&
.c:643
[< inline >] SYSC_sendto net/socket.c:1797
[] SyS_sendto+0x178/0x1d8 net/socket.c:1761
CVE-2016-8399
Reported-by: Qidan He <i...@flanker017.me>
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees C
et/socket.c:643
[< inline >] SYSC_sendto net/socket.c:1797
[] SyS_sendto+0x178/0x1d8 net/socket.c:1761
CVE-2016-8399
Reported-by: Qidan He <i...@flanker017.me>
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees C
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook <keesc...@chromium.
On Tue, Mar 21, 2017 at 7:03 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Tue, 2017-03-21 at 16:51 -0700, Kees Cook wrote:
>
>> Am I understanding you correctly that you'd want something like:
>>
>> refcount.h:
>> #ifdef UNPROTECTED_REFCOUNT
>&
shows actual
problems, let's examine it and find a solution for that as a separate
part of this work without blocking this migration.
-Kees
[1] https://outflux.net/blog/archives/2016/10/18/security-bug-lifetime/
[2] http://kernsec.org/wiki/index.php/Bug_Classes/Integer_overflow
--
Kees Cook
Pixel Security
ke to find as well. Just comparing
cycles between refcount implementations, while interesting, doesn't
show us real-world performance changes, which is what we need to
measure.
Is Eric's "20 concurrent 'netperf -t UDP_STREAM'" example (from
elsewhere in this email thread) real-world meaningful enough?
-Kees
--
Kees Cook
Pixel Security
On Tue, Mar 21, 2017 at 2:23 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote:
>
>> Yeah, this is exactly what I'd like to find as well. Just comparing
>> cycles between refcount implementations, while interesting, doesn
rsen <ty...@docker.com>
> CC: Daniel Borkmann <dan...@iogearbox.net>
> CC: Alexei Starovoitov <a...@kernel.org>
> CC: Kees Cook <keesc...@chromium.org>
> CC: Mickaël Salaün <m...@digikod.net>
Cool! This closes the race condition on producing the JIT vs
of undesignated NULLs.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
net/unix/af_unix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 928691c43408..6a7fe7660551 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@
On Wed, Apr 19, 2017 at 2:51 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
> On 19/04/2017 02:02, Kees Cook wrote:
>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün <m...@digikod.net> wrote:
>>> This is useful to return an information about the erro
On Wed, Apr 19, 2017 at 3:05 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
>
> On 20/04/2017 00:02, Kees Cook wrote:
>> On Wed, Apr 19, 2017 at 2:51 PM, Mickaël Salaün <m...@digikod.net> wrote:
>>>
>>> On 19/04/2017 02:02, Kees Cook wrote:
>>&g
On Wed, Apr 19, 2017 at 3:18 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
> On 19/04/2017 00:47, Mickaël Salaün wrote:
>>
>> On 19/04/2017 00:23, Kees Cook wrote:
>>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün <m...@digikod.net> wrote:
>>>
On Wed, Apr 19, 2017 at 3:03 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
> On 19/04/2017 01:40, Kees Cook wrote:
>> On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler <ca...@schaufler-ca.com>
>> wrote:
>>> On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
&g
On Wed, Mar 8, 2017 at 3:55 PM, Laura Abbott <labb...@redhat.com> wrote:
> On 03/08/2017 02:36 PM, Kees Cook wrote:
>> On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann <dan...@iogearbox.net> wrote:
>>> [ 28.474232] rodata_test: test data was not read only
>>&g
On Mon, Mar 6, 2017 at 10:11 AM, Kees Cook <keesc...@chromium.org> wrote:
> On Fri, Mar 3, 2017 at 7:23 PM, Daniel Borkmann <dan...@iogearbox.net> wrote:
>> Latter shows that memory protecting the kernel seems not working either
>> on i386 (!). Test suite output:
>&
: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge")
> Reported-by: Fengguang Wu <fengguang...@intel.com>
> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net>
> Cc: Borislav Petkov <b...@suse.de>
> Cc: Linus Torvalds <torva...@linux-foundation.org>
&
echeck under Qemu 2.7.1. Do you see these failures on real hardware?
-Kees
--
Kees Cook
Pixel Security
gh. I wonder about __set_pmd_pte(), but I haven't looked closely
at x86 paging code before...
>
> [1] https://lkml.org/lkml/2017/3/2/648
>
> Reported-by: Fengguang Wu <fengguang...@intel.com>
> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net>
> Cc: Laura Abbot
While unlikely, this makes sure the workqueue name won't be processed
as a format string.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogi
While unlikely, this makes sure any format strings in the device name
can't exposure information via the resulting workqueue name.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/net/ethernet/wiznet/w5100.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
> to store multiple task->security, which is needed for a stackable LSM
> like Landlock, but we could move the events there if needed in the future.
It does stand out to me that the only thing landlock is using seccomp
for is its syscall... :P
-Kees
--
Kees Cook
Pixel Security
/* prog->subtype is __GFP_ZERO */
> + if (copy_from_user(>subtype,
> + u64_to_user_ptr(attr->prog_subtype), size)
> + != 0)
It might be worth adding a comment here about how the ToCToU of the
check-then-copy doesn't matter in this case, since it's just a
future-proofing of bits, etc.
-Kees
--
Kees Cook
Pixel Security
y Lutomirski <l...@amacapital.net>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: James Morris <james.l.mor...@oracle.com>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Serge E. Hallyn &l
;a...@kernel.org>
> Cc: Andy Lutomirski <l...@amacapital.net>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: James Morris <james.l.mor...@oracle.com>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Serge E
cgroup handling
>
> Signed-off-by: Mickaël Salaün <m...@digikod.net>
> Cc: Alexei Starovoitov <a...@kernel.org>
> Cc: Andy Lutomirski <l...@amacapital.net>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: David S. Miller <da...@davemloft.net>
On Tue, Apr 18, 2017 at 3:44 PM, Mickaël Salaün <m...@digikod.net> wrote:
>
> On 19/04/2017 00:17, Kees Cook wrote:
>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün <m...@digikod.net> wrote:
>>> Handle 33 filesystem-related LSM hooks for
1 - 100 of 602 matches
Mail list logo
