f
> [ 1563.658318] Code: 8b 44 24 78 41 39 d8 77 57 41 f6 44 24 34 01 0f 85 24 01
> 00 00 45 85 ff 0f 84 40 04 00 00 49 8b 04 24 49 39 c2 0f 84 1d 02 00 00 <8b>
> 50 28 41 8b 1e 39 d3 0f 88 f4 03 00 00 49 89 c4 29 d3 41 f6
> [ 1563.658365] RIP: tcp_recvmsg+0x1eb/0xb40 RSP: b77e010f7cf8
> [ 1563.658366] CR2:
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash di
On Fri, Jun 29, 2018 at 4:47 PM, Daniel Borkmann wrote:
> On 06/29/2018 08:42 PM, Kees Cook wrote:
>> On Thu, Jun 28, 2018 at 2:34 PM, Daniel Borkmann
>> wrote:
>>> Kees suggested that if set_memory_*() can fail, we should annotate it with
>>> __must_ch
pened, the transition from RW -> RO could
> be made more robust that way, while subsequent RO -> RW transition /must/
> continue guaranteeing to always succeed the undo part.
Does this mean we can have BPF filters that aren't read-only then?
What's the situation where set_memory_ro() fai
-2936,7 +2936,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct
>> nlmsghdr *nlh,
>> }
>>
>> if (m_ops) {
>> - if (ops->slave_maxtype > RTNL_SLAVE_MAX_TYPE)
>> + if (m_ops->slave_maxtype > RTNL_SLAVE_MAX_TYPE)
>> return -EINVAL;
>
>
> Oh nice
>
> CC Kees Cook.
Argh. Thank you, yes.
Acked-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
default 1280 if (!64BIT && PARISC)
default 1024 if (!64BIT && !PARISC)
default 2048 if 64BIT
Just dropping the defconfig there should fix it. (And I think it was
just a mistake to port that value when splitting the um defconfig in
commit e40f04d040c6 ("arch/um: make it work with defconfig and
x86_64").
-Kees
--
Kees Cook
Pixel Security
th file interfaces,
I'm cautious to add a new blob interface. Maybe just pull all the
blob-finding/loading into the interface, and just make it something
like fork_usermode_kmod(struct module *mod, struct umh_info *info) ?
-Kees
--
Kees Cook
Pixel Security
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
> On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
>> On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
>> > + This used to be the default firmw
ing.
>
> As for the rename that you wanted, perhaps we can do this late in the
> merge window considering we're at rc4 now. I can prep something up for
> that later.
>
> Question, and specially rants are warmly welcomed.
I sent some typo catches, but with those fixed, please c
longer required unless you have a special firmware file that
> - resides in a non-standard path. Moreover, the udev support has
> - been deprecated upstream.
> + Enabling this option forces a sysfs userspace fallback mechanism
> + to be used for all firmware requests which explicitly do not
> disable a
> + a fallback mechanism. Firmware calls which do prohibit a fallback
> + mechanism is request_firmware_direct(). This option is kept for
> + backward compatibility purposes given this precise mechanism can
> also
> + be enabled by setting the proc sysctl value to true:
> +
> + /proc/sys/kernel/firmware_config/force_sysfs_fallback
>
> If you are unsure about this, say N here.
>
> +endif # FW_LOADER
> +endmenu
> +
> config WANT_DEV_COREDUMP
> bool
> help
> --
> 2.17.0
>
-Kees
--
Kees Cook
Pixel Security
; You could make the bitmap part of the dsa_switch structure. This is
> allocated by dsa_switch_alloc() and is passed the number of ports.
> Doing the allocation there means you don't need to worry about it
> failing in dsa_switch_mdb_add() or dsa_switch_vlan_add().
Are dsa_switch_mdb_add() and dsa_switch_vlan_add() guaranteed to be
single-threaded?
-Kees
--
Kees Cook
Pixel Security
On Wed, May 2, 2018 at 1:54 AM, Jose Abreu <jose.ab...@synopsys.com> wrote:
> Hi Kees,
>
> On 01-05-2018 22:01, Kees Cook wrote:
>> In the quest to remove all stack VLAs from the kernel[1], this switches
>> the "status" stack buffer to use the existing small
[1]
http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/etherne
andreaschrist...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v4:
- actually remove memset(). :)
v3:
- adjust Subject and commit log (Steffen)
- use "= { }" instead of memset() (Stefano)
v2:
- use XFRM_MAX_DEPTH for "count" array (Steffen and Mathias).
it/commit/?h=ath-next=9c27489a34548913baaaf3b2776e05d4a9389e3e
Ah! Cool, no worries. I didn't see that in linux-next yet. :)
Thanks!
-Kees
--
Kees Cook
Pixel Security
ed-off-by: Kees Cook <keesc...@chromium.org>
---
v3: replace FFT_NUM_SAMPLES as a #define (Joe)
---
drivers/net/wireless/ath/ath9k/dfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/dfs.c
b/drivers/net/wireless/ath/ath9k/dfs.c
index
andreaschrist...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v3:
- adjust Subject and commit log (Steffen)
- use "= { }" instead of memset() (Stefano)
- reorder variables (Stefano)
v2:
- use XFRM_MAX_DEPTH for "count" array (Steffen and Mathias).
--
locations. */
+ if (iv_size > MAX_IV_SIZE) {
+ rc = -EINVAL;
+ goto free_priv;
+ }
+
cctx->prepend_size = TLS_HEADER_SIZE + nonce_size;
cctx->tag_size = tag_size;
cctx->overhead_size = cctx->prepend_size + cctx->tag_size;
--
le trying to tighten the
CONFIG_FORTIFY_SOURCE checking.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index aad5658
On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Sat, Mar 17, 2018 at 1:07 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only
>> does
ning: variable length array is used
./include/linux/mm.h:1567: error: first argument to
‘__builtin_choose_expr’ not a constant
6.8 is happy with it (of course).
I do think the earlier version (without the
sizeof-hiding-builting_constant_p) provides a template for a
const_max() that both you and R
this is the same problem of using __builtin_constant_p() in
4.4 that we hit earlier? :(
-Kees
--
Kees Cook
Pixel Security
Patch 1 adds const_max_t(), patch 2 uses it in all the places max()
was used for stack arrays. Commit log from patch 1:
---snip---
kernel.h: Introduce const_max_t() for VLA removal
In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla. However, this warning is
() instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/input/touchscreen/cyttsp4_core.c | 2 +-
fs/btrfs/tree-checker.c | 3 ++-
lib/vsprintf.c | 5 +++--
net/ipv4/
://lkml.org/lkml/2018/3/10/170
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/kernel.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3fd291503576..e14531781568 100644
--- a/include/linux/ke
argument. Thanks!
-Kees
--
Kees Cook
Pixel Security
On Thu, Mar 15, 2018 at 4:34 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Thu, Mar 15, 2018 at 3:46 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> So, AIUI, I can either get strict type checking, in which case, this
>> is rejected (which
__error_not_positive_arg(); \
>> if ((y) < 0) \
>> __error_not_positive_arg(); \
>> __builtin_choose_expr((x) > (y), (x), (y)); \
>> })
>>
>
> Nevermind.
On Thu, Mar 15, 2018 at 3:23 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Thu, Mar 15, 2018 at 3:16 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> size_t __error_not_const_arg(void) \
>> __compiletime_error("const_max() used with non-c
On Thu, Mar 15, 2018 at 2:42 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Thu, Mar 15, 2018 at 12:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> To gain the ability to compare differing types, the arguments are
>> explicitly cast
() instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/input/touchscreen/cyttsp4_core.c | 2 +-
fs/btrfs/tree-checker.c | 3 ++-
lib/vsprintf.c | 4 ++--
net/ipv4/
I'm calling this "v4" since the last effort at this was v3, even
if it's a different approach. Patch 1 adds const_max(), patch 2
uses it in all the places max() was used for stack arrays. Commit
log from patch 1:
---snip---
kernel.h: Introduce const_max() for VLA removal
In the effort to remove
))];
[1] https://lkml.org/lkml/2018/3/7/621
[2] https://lkml.org/lkml/2018/3/10/170
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/kernel.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3fd291
313201757.GK8631@eros>
X-Mailer: Mutt 1.5.24 (2015-08-30)
User-Agent: Mutt/1.5.24 (2015-08-30)
Your most recently email shows "Tobin C. Harding" though, and also
sent with Mutt...
Do you have multiple Mutt configurations? Is something lacking a
"From" header insertion and your MTA is filling it in for you from
your username?
-Kees
--
Kees Cook
Pixel Security
On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton
<a...@linux-foundation.org> wrote:
> On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook <keesc...@chromium.org> wrote:
>
>> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
>> <torva...@linux-foundation.org> wrote:
KCFLAGS=-Wval and checking net/ipv6/proc.c:
net/ipv6/proc.c: In function ‘snmp6_seq_show_item’:
net/ipv6/proc.c:198:2: warning: ISO C90 forbids array ‘buff’ whose
size can’t be evaluated [-Wvla]
unsigned long buff[SNMP_MIB_MAX];
^~~~
-Kees
--
Kees Cook
Pixel Security
's not a "constant expression", so the compiler
frontend still yells about it under -Wvla. I would characterize this
mainly as a fix for "accidental VLA" or "misdetected VLA" or something
like that. AIUI, there really isn't a functional change here.
-Kees
--
Kees Cook
Pixel Security
count[maxclass];
>> + int count[XFRM_MAX_DEPTH];
>>
>> memset(count, 0, sizeof(count));
>
> Can you perhaps initialize 'count' instead of calling memset(), now?
Do you mean:
int count[XFRM_MAX_DEPTH] = { };
instead of the memset()?
I thought the compiler would resolve these both to the same thing? The
former looks better though! :)
-Kees
--
Kees Cook
Pixel Security
On Fri, Mar 9, 2018 at 10:10 PM, Miguel Ojeda
<miguel.ojeda.sando...@gmail.com> wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook
On Fri, Mar 9, 2018 at 5:30 PM, Kees Cook <keesc...@chromium.org> wrote:
> --
> Kees Cook
> Pixel SecurityOn
> [...]
WTF, gmail just blasted HTML into my explicitly plain-text email?! Apologies...
--
Kees Cook
Pixel SecurityOn
Fri, Mar 9, 2018 at 5:30 PM, Kees Cook mailto:kee
l "multi-eval max only for constants" macro (meh)
- add gcc version checks around this and similarly for -Wvla in the future (eww)
- raise gcc version (yikes)
-Kees
--
Kees Cook
Pixel SecurityOn
Fri, Mar 9, 2018 at 4:38 PM, Linus Torvalds mailto:torva...@linux-foundation.org;
targe
On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook <keesc...@chromium.org> wrote:
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max
90 forbids variable length array ‘buff64’
[-Wvla]
Based on an earlier patch from Josh Poimboeuf.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v3:
- drop __builtin_types_compatible_p() (Rasmus, Linus)
v2:
- fix copy/paste-o max1_/max2_ (ijc)
- clarify "compile-time" constant in c
On Fri, Mar 9, 2018 at 10:50 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Fri, Mar 9, 2018 at 10:43 AM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> Module loading (via kernel_read_file()) already uses
>> deny_write_access(), and so does do
in the new implementation, I think we'd be covered here.
-Kees
--
Kees Cook
Pixel Security
mm? The __builtin_types_compatible_p() just doesn't seem to matter
> for the only thing I thought it was there for.
Yup, agreed. I'll drop it.
-Kees
--
Kees Cook
Pixel Security
container
triggers an autoload, the result runs in the init_ns. So, really,
there's nothing new from my perspective, except that it's in userspace
instead of in the kernel.
Perhaps it's an orthogonal concern.
-Kees
--
Kees Cook
Pixel Security
ey have very different effects on the system, for
example. The issue is about validating intent with target. "Is this
kernel module allowed?" and "Is this umh ELF allowed?" are better
questions that "Is something loaded through finit_module() allowed?"
Note already that the LSM distinguishes between many other file types
in kernel_read_file*().
-Kees
--
Kees Cook
Pixel Security
On Thu, Mar 8, 2018 at 3:48 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Thu, Mar 8, 2018 at 1:40 PM, Kees Cook <keesc...@chromium.org> wrote:
>> +#define __min(t1, t2, x, y)\
>> + __builtin_choose_
> sub_info->retval = retval;
> /*
> @@ -393,6 +397,20 @@ struct subprocess_info *call_usermodehelper_setup(const
> char *path, char **argv,
> }
> EXPORT_SYMBOL(call_usermodehelper_setup);
>
> +struct subprocess_info *call_usermodehelper_setup_file(struct file *file)
> +{
> + struct subprocess_info *sub_info;
> +
> + sub_info = kzalloc(sizeof(struct subprocess_info), GFP_KERNEL);
> + if (!sub_info)
> + return NULL;
> +
> + INIT_WORK(_info->work, call_usermodehelper_exec_work);
> + sub_info->path = "/dev/null";
> + sub_info->file = file;
This use of "/dev/null" here and in execve is just wrong. It _does_
have a path and filename...
Anyway, interesting idea. I think it _can_ work, it just needs much
much more careful security boundaries and to solve our autoloading
exposures too.
-Kees
--
Kees Cook
Pixel Security
90 forbids variable length array ‘buff64’
[-Wvla]
Based on an earlier patch from Josh Poimboeuf.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v2:
- fix copy/paste-o max1_/max2_ (ijc)
- clarify "compile-time" constant in comment (Rasmus)
- clean up formatting on min_t()/max_t()
-
On Thu, Mar 8, 2018 at 2:12 PM, Rasmus Villemoes
<li...@rasmusvillemoes.dk> wrote:
> On 8 March 2018 at 21:39, Kees Cook <keesc...@chromium.org> wrote:
>> However, this works for me:
>>
>> #define __new_max(t1, t2, max1, max2, x, y)
On Thu, Mar 8, 2018 at 2:18 PM, Andrew Morton <a...@linux-foundation.org> wrote:
> On Thu, 8 Mar 2018 13:40:45 -0800 Kees Cook <keesc...@chromium.org> wrote:
>
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[
90 forbids variable length array ‘buff64’
[-Wvla]
Based on an earlier patch from Josh Poimboeuf.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/kernel.h | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/include/
On Thu, Mar 8, 2018 at 11:57 AM, Rasmus Villemoes
<li...@rasmusvillemoes.dk> wrote:
> On 2018-03-08 16:02, Josh Poimboeuf wrote:
>> On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
>>> This series adds SIMPLE_MAX() to be used in places where a stack arr
On Thu, Mar 8, 2018 at 7:02 AM, Josh Poimboeuf <jpoim...@redhat.com> wrote:
> On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
>> This series adds SIMPLE_MAX() to be used in places where a stack array
>> is actually fixed, but the compiler still warns about VLA usag
Hi,
I don't see fe9c842695e2 ("NFC: llcp: Limit size of SDP URI") queued
up for stable. Can this one be added please? This is a buffer overflow
fix.
Thanks!
-Kees
--
Kees Cook
Pixel Security
In the quest to remove all stack VLAs from the kernel[1], this refactors
the stack array size calculation to avoid using max(), which makes the
compiler think the size isn't fixed.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
net/ipv4/proc.
In the quest to remove all stack VLAs from the kernel[1], this refactors
the stack array size calculation to avoid using max(), which makes the
compiler think the size isn't fixed.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
fs/btrf
This series adds SIMPLE_MAX() to be used in places where a stack array
is actually fixed, but the compiler still warns about VLA usage due to
confusion caused by the safety checks in the max() macro.
I'm sending these via -mm since that's where I've introduced SIMPLE_MAX(),
and they should all
like a variable size
to the compiler.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/kernel.h | 11 +++
lib/vsprintf.c | 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/kernel.
et's fix it properly instead of adding more hacks to Makefiles
It is being fixed properly -- the detection code is being moved out of
Makefile into Kconfig, at which point this won't be as weird as it is.
If KBUILD_CPPFLAGS won't work for you, I'm not hugely opposed to
switching the task_struct
of the old file in your tree...
-Kees
--
Kees Cook
Pixel Security
here are a number of issues with its logic
in detecting and enabling, and another draft at solving it is under
development.
-Kees
--
Kees Cook
Pixel Security
On Tue, Feb 27, 2018 at 8:59 AM, chris hyser <chris.hy...@oracle.com> wrote:
> On 02/27/2018 11:00 AM, Kees Cook wrote:
>>
>> On Tue, Feb 27, 2018 at 6:53 AM, chris hyser <chris.hy...@oracle.com>
>> wrote:
>>>
>>> On 02/26/2018 11:38 PM, Kees Cook
On Tue, Feb 27, 2018 at 6:53 AM, chris hyser <chris.hy...@oracle.com> wrote:
> On 02/26/2018 11:38 PM, Kees Cook wrote:
>>
>> On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski <l...@amacapital.net>
>> wrote:
>>>
>>> 3. Straight-up bugs. Those are
On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski <l...@amacapital.net> wrote:
>> On Feb 26, 2018, at 3:20 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> On Mon, Feb 26, 2018 at 3:04 PM, Alexei Starovoitov
>> <alexei.starovoi...@gmail.com> wrote:
>
drastic expansion of the seccomp
attack surface. :) For me, the driving feature is if we can get
Tycho's notifier implemented in eBPF. The speed improvements, as far
as I'm concerned, aren't sufficient to add eBPF to seccomp. They are
certainly a nice benefit, but seccomp must be very conservative about
adding attack surface.
-Kees
--
Kees Cook
Pixel Security
inue have its own verifier, I *think* this
will be fine, though, again I remain concerned about maps, etc. I'm
still reviewing these patches and how they might provide overlap with
Tycho's needs too, etc.
-Kees
--
Kees Cook
Pixel Security
copperhead/linux-hardened/issues/72
--
Kees Cook
Pixel Security
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
No reply from linux-wireless, so sending to netdev directly now...
---
net/nfc/llcp_commands.c | 4
net/nfc/netlink.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_
id() at the end of the 306-syscall filter 2452
> seccomp using a 306-syscall-sized EBPF hash map 800
> cBPF filter using a binary tree 922
I still think that's a crazy filter. :) It should be inverted to just
check the 26 syscalls and a final "greater than" test. I would expect
it to be faster still. :)
-Kees
--
Kees Cook
Pixel Security
return (size == FIELD_SIZEOF(struct seccomp_data, arch));
> + case bpf_ctx_range(struct seccomp_data, instruction_pointer):
> + return (size == FIELD_SIZEOF(struct seccomp_data,
> +instruction_pointer));
> + }
> +
> + return false;
> +}
> +
> +static const struct bpf_func_proto *
> +seccomp_func_proto(enum bpf_func_id func_id)
> +{
> + switch (func_id) {
> + case BPF_FUNC_get_current_uid_gid:
> + return _get_current_uid_gid_proto;
> + case BPF_FUNC_trace_printk:
> + if (capable(CAP_SYS_ADMIN))
> + return bpf_get_trace_printk_proto();
> + default:
> + return NULL;
> + }
> +}
This makes me so uncomfortable. :) Why is uid/gid needed? Why add
printk support here? (And why is it CAP_SYS_ADMIN checked if the
entire filter is CAP_SYS_ADMIN checked before being attached?)
> +
> +const struct bpf_prog_ops seccomp_prog_ops = {
> +};
> +
> +const struct bpf_verifier_ops seccomp_verifier_ops = {
> + .get_func_proto = seccomp_func_proto,
> + .is_valid_access= seccomp_is_valid_access,
> +};
> +#endif /* CONFIG_SECCOMP_FILTER_EXTENDED */
> +
> static struct ctl_path seccomp_sysctl_path[] = {
> { .procname = "kernel", },
> { .procname = "seccomp", },
> --
> 2.14.1
>
-Kees
--
Kees Cook
Pixel Security
if (ctx->nr == __NR_sched_yield)
> + return SECCOMP_RET_ERRNO | EPERM;
> +
> + return SECCOMP_RET_ALLOW;
> +}
> +
> +char _license[] SEC("license") = "aGPL";
Nit: these should check architecture before syscall number. Since
they're samples, people look at them for and copy them regularly, they
should be as safe/correct as possible.
-Kees
--
Kees Cook
Pixel Security
On Tue, Feb 13, 2018 at 9:31 AM, Sargun Dhillon <sar...@sargun.me> wrote:
> On Tue, Feb 13, 2018 at 9:02 AM, Jessie Frazelle <m...@jessfraz.com> wrote:
>> On Tue, Feb 13, 2018 at 11:29 AM, Sargun Dhillon <sar...@sargun.me> wrote:
>>> On Tue, Feb 1
reate mode 100644 samples/bpf/seccomp1_kern.c
> create mode 100644 samples/bpf/seccomp1_user.c
> create mode 100644 samples/bpf/seccomp2_kern.c
> create mode 100644 samples/bpf/seccomp2_user.c
>
> --
> 2.14.1
>
--
Kees Cook
Pixel Security
On Fri, Feb 9, 2018 at 7:16 AM, David Miller <da...@davemloft.net> wrote:
> From: Kees Cook <keesc...@chromium.org>
> Date: Wed, 7 Feb 2018 17:44:38 -0800
>
>> Most callers of put_cmsg() use a "sizeof(foo)" for the length argument.
>> Within put_cmsg(), a
sg net/socket.c:2368 [inline]
SyS_recvmmsg+0xc4/0x160 net/socket.c:2352
entry_SYSCALL_64_fastpath+0x29/0xa0
Reported-by: syzbot+e2d6cfb305e9f3911...@syzkaller.appspotmail.com
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Kees Cook <k
On Wed, Feb 7, 2018 at 3:19 AM, David Miller <da...@davemloft.net> wrote:
> From: Kees Cook <keesc...@chromium.org>
> Date: Tue, 6 Feb 2018 04:31:50 +1100
>
>> On Tue, Feb 6, 2018 at 2:03 AM, David Miller <da...@davemloft.net> wrote:
>>> From: Kees Cook &l
On Tue, Feb 6, 2018 at 2:03 AM, David Miller <da...@davemloft.net> wrote:
> From: Kees Cook <keesc...@chromium.org>
> Date: Fri, 2 Feb 2018 02:27:49 -0800
>
>> @@ -343,6 +343,14 @@ struct ucred {
>>
>> extern int move_addr_to_kernel(void __user *uaddr, int u
mmsg net/socket.c:2368 [inline]
SyS_recvmmsg+0xc4/0x160 net/socket.c:2352
entry_SYSCALL_64_fastpath+0x29/0xa0
Reported-by: syzbot+e2d6cfb305e9f3911...@syzkaller.appspotmail.com
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Kees Cook <keesc...@chro
ket.c:2352
entry_SYSCALL_64_fastpath+0x29/0xa0
Reported-by: syzbot+e2d6cfb305e9f3911...@syzkaller.appspotmail.com
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/socket.h | 18 +-
n
On Tue, Jan 23, 2018 at 4:01 AM, Santosh Shilimkar
<santosh.shilim...@oracle.com> wrote:
> On 1/22/2018 3:24 AM, Kees Cook wrote:
>>
>> As described in: https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>
>> Attempting an RDS connection from the IP address o
is fix appears to have been carried by at least RedHat, Oracle, and
Ubuntu for several years.
CVE-2012-2372
Reported-by: Honggang Li <ho...@redhat.com>
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This is what I get for researching CVE lifetimes...
---
On Thu, Jan 18, 2018 at 1:31 PM, Laura Abbott <labb...@redhat.com> wrote:
> On 01/10/2018 06:02 PM, Kees Cook wrote:
>>
>> From: David Windsor <d...@nullcore.net>
>>
>> The autoclose field can be copied with put_user(), so there is no need to
>> use cop
On Mon, Jan 15, 2018 at 4:24 AM, Dave P Martin <dave.mar...@arm.com> wrote:
> On Thu, Jan 11, 2018 at 02:03:05AM +0000, Kees Cook wrote:
>> This whitelists the FPU register state portion of the thread_struct for
>> copying to userspace, instead of the default entire structu
On Thu, Jan 11, 2018 at 9:06 AM, Christopher Lameter <c...@linux.com> wrote:
> On Wed, 10 Jan 2018, Kees Cook wrote:
>
>> diff --git a/mm/slab.h b/mm/slab.h
>> index ad657ffa44e5..7d29e69ac310 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>&
On Thu, Jan 11, 2018 at 2:24 AM, Russell King - ARM Linux
<li...@armlinux.org.uk> wrote:
> On Wed, Jan 10, 2018 at 06:03:06PM -0800, Kees Cook wrote:
>> ARM does not carry FPU state in the thread structure, so it can declare
>> no usercopy whitelist at all.
>
> This com
On Thu, Jan 11, 2018 at 9:01 AM, Theodore Ts'o <ty...@mit.edu> wrote:
> On Wed, Jan 10, 2018 at 06:02:45PM -0800, Kees Cook wrote:
>> The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data
>> and therefore contained in the ext4_inode_cache slab cache, need
&g
complex conflicts.
Thanks! And yes, confirmed, the kspp tree version should be used to
resolve this conflict.
-Kees
--
Kees Cook
Pixel Security
ctures with usercopy hardening
enabled.
For now, allow writing to the entire struct on all architectures.
The KVM tree will not refine this to an architecture-specific
subset of struct kvm_vcpu_arch.
Cc: kernel-harden...@lists.openwall.com
Cc: Kees Cook <keesc...@chromium.org>
Cc: Christian Borntraeg
c: Ingo Molnar <mi...@kernel.org>
Cc: James Morse <james.mo...@arm.com>
Cc: "Peter Zijlstra (Intel)" <pet...@infradead.org>
Cc: Dave Martin <dave.mar...@arm.com>
Cc: zijun_hu <zijun...@htc.com>
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by:
es: adjust commit log, provide usage trace]
Cc: Luis de Bethencourt <lui...@kernel.org>
Cc: Salah Triki <salah.tr...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
Acked-by: Luis de Bethencourt <lui...@kernel.org>
---
fs/befs/linuxvfs.c | 14 +-
1 fil
This updates the USERCOPY_HEAP_FLAG_* tests to USERCOPY_HEAP_WHITELIST_*,
since the final form of usercopy whitelisting ended up using an offset/size
window instead of the earlier proposed allocation flags.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/misc/lkdtm.h
v5:
- add Acks
- split stddef changes into separate patch
- further refactor reporting code for readability
- adjust enforcement code for greater readability
v4:
- refactor reporting to include offset and remove %p
- explicitly WARN by default for the whitelisting
- add KVM whitelists and harden
Instead of doubling the size, push the start position up by 16 bytes to
still trigger an overflow. This allows to verify that offset reporting
is working correctly.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/misc/lkdtm_usercopy.c | 13 +
1 file changed, 9 inse
available to the slab allocators, and adds new "detail"
and "offset" arguments.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
mm/slab.h | 6 ++
mm/usercopy.c | 24 +++-
tools/objtool/check.c | 1 +
3 files changed, 26
in understanding hardened usercopy bugs.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/slab.h | 12 +++
mm/slab.c| 8 ++---
mm/slub.c| 14
mm/usercopy.c| 95 +++-
4 files chang
sen" <martin.peter...@oracle.com>
Cc: linux-s...@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/scsi_lib.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1
+ lustre assert uses:
$ git grep -E 'sizeof\(\(\((struct )?[a-zA-Z_]+ \*\)0\)->' | \
grep -v staging/lustre | wc -l
65
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
include/linux/stddef.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux
1 - 100 of 602 matches
Mail list logo
