In the continuing effort to avoid kernel addresses leaking to unprivileged
users, this patch switches to %pK for /proc/dri/*/vma.
Signed-off-by: Kees Cook kees.c...@canonical.com
---
drivers/gpu/drm/drm_info.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git
being dense, but what problem is %pK causing here? I'd be
happy to help get it fixed.
-Kees
--
Kees Cook
ChromeOS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings b...@decadent.org.uk wrote:
On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote:
Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
leak kernel
or 3.4.
That works too. :)
--
Kees Cook
ChromeOS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user and value formatting code.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm
Masks kernel address info-leak in object dumps with the %pK suffix,
so they cannot be used to target kernel memory corruption attacks if
the kptr_restrict sysctl is set.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
1
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
1 file changed, 5 insertions(+), 1 deletion
The boxes parameter points into userspace memory. It should be verified
like any other operation against user memory.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Mon, Mar 11, 2013 at 1:51 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Mar 11, 2013 at 12:26:30PM -0700, Kees Cook wrote:
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Do we really need to copy the interface documentation
On Mon, Mar 11, 2013 at 1:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Mar 11, 2013 at 12:27:16PM -0700, Kees Cook wrote:
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
Seems a sensible check
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
Signed-off-by: Kees Cook keesc...@chromium.org
Reported-by: Pinkie Pie
Cc: sta...@vger.kernel.org
---
v2:
- move check into validate_exec_list
---
drivers/gpu/drm
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
v2:
- rewrote comment, thanks to Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6
On Mon, Mar 11, 2013 at 3:00 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
I'd keep the return value
On Mon, Mar 11, 2013 at 4:03 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Sun, Mar 10, 2013 at 02:10:06PM -0700, Kees Cook wrote:
This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
CVE-2013-0913
v3: collapse test, improve comment
v2: move check into validate_exec_list
Signed-off-by: Kees Cook keesc...@chromium.org
Reported-by: Pinkie Pie
Cc: sta
This replaces the open-coded divisions in the debugfs code by calls
to do_div().
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
sent a follow-up patch to fix this.
-Kees
--
Kees Cook
Chrome OS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
It is possible to wrap
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook keesc...@chromium.org
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers
On Wed, May 8, 2013 at 12:22 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Am Dienstag, den 07.05.2013, 12:32 -0700 schrieb Kees Cook:
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Good fine. Do you
The boxes parameter points into userspace memory. It should be verified
like any other operation against user memory.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
:1943:27: warning: ‘score’ may be used
uninitialized in this function [-Wuninitialized]
-Kees
--
Kees Cook
Chrome OS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
he logic, but I was not sure it was the authors'
> intention.
>
> Signed-off-by: Masahiro Yamada
Sounds good to me! :)
Acked-by: Kees Cook
--
Kees Cook
Chrome OS & Brillo Security
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
---
drivers/gpu/drm/amd
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
---
drivers/gpu/drm/virtio
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
---
drivers/gpu/drm/ttm
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
---
drivers/gpu/drm
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
---
drivers/gpu/drm/vmwgfx
y 16 December 2016 16:59:29, Kees Cook wrote:
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using designated initializers.
>
> Can you please elaborate what you mean with that sentence?
Hi! Sure: the coming (and optional) gcc plugin
While zone->name is currently hard coded, the call to kobject_init_and_add()
should follow the more defensive argument list usage (as already done in
other places in ttm_memory.c) where "%s" is used instead of directly passing
in a variable as a format string.
Signed-off-
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
On Wed, May 8, 2013 at 12:22 AM, Paul Menzel
wrote:
> Am Dienstag, den 07.05.2013, 12:32 -0700 schrieb Kees Cook:
>> This reduces the size of the stack frame when calling request_module().
>> Performing the sprintf before the call is not needed.
>
> Good fine. Do you
The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.
Signed-off-by: Kees Cook
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
drivers/gpu/drm/i915/i915_irq.c:1943:27: warning: ?score? may be used
uninitialized in this function [-Wuninitialized]
-Kees
--
Kees Cook
Chrome OS Security
0x4600, priv->vdiv);
}
Coverity noticed it as CID 1135671. If it's intentional, it might be
nice to add a "fall through" comment there.
Coverity also complained about read_pll (CID 1135670) where post_div
could (unlikely) be 0 and used for a divide-by-zero.
Thanks!
-Kee
This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user and value formatting code.
Signed-off-by: Kees Cook
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 394
Masks kernel address info-leak in object dumps with the %pK suffix,
so they cannot be used to target kernel memory corruption attacks if
the kptr_restrict sysctl is set.
Signed-off-by: Kees Cook
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
1 file changed, 1
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Signed-off-by: Kees Cook
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.
Signed-off-by: Kees Cook
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
Signed-off-by: Kees Cook
Reported-by: Pinkie Pie
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 --
1 file changed, 8
On Mon, Mar 11, 2013 at 1:51 PM, Chris Wilson
wrote:
> On Mon, Mar 11, 2013 at 12:26:30PM -0700, Kees Cook wrote:
>> This clarifies the comment above the access_ok check so a missing
>> VERIFY_READ doesn't alarm anyone.
>
> Do we really need to copy the in
On Mon, Mar 11, 2013 at 1:52 PM, Chris Wilson
wrote:
> On Mon, Mar 11, 2013 at 12:27:16PM -0700, Kees Cook wrote:
>> It is possible to wrap the counter used to allocate the buffer for
>> relocation copies. This could lead to heap writing overflows.
>
> Seems a sensible che
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
Signed-off-by: Kees Cook
Reported-by: Pinkie Pie
Cc: stable at vger.kernel.org
---
v2:
- move check into validate_exec_list
---
drivers/gpu/drm/i915
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Signed-off-by: Kees Cook
Cc: Daniel Vetter
---
v2:
- rewrote comment, thanks to Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
1 file changed, 5 insertions(+), 1
On Mon, Mar 11, 2013 at 3:00 PM, Chris Wilson
wrote:
> On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
>> It is possible to wrap the counter used to allocate the buffer for
>> relocation copies. This could lead to heap writing overflows.
>
> I'd keep the retu
This replaces the open-coded divisions in the debugfs code by calls
to do_div().
Signed-off-by: Kees Cook
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers
On Mon, Mar 11, 2013 at 4:03 PM, Daniel Vetter wrote:
> On Sun, Mar 10, 2013 at 02:10:06PM -0700, Kees Cook wrote:
>> This replaces the manual read/write routines in debugfs with the common
>> simple attribute helpers. Doing this gets rid of repeated copy/pasting
>> of cop
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
CVE-2013-0913
v3: collapse test, improve comment
v2: move check into validate_exec_list
Signed-off-by: Kees Cook
Reported-by: Pinkie Pie
Cc: stable
reverted that commit for today.
Ah-ha, thanks. I've sent a follow-up patch to fix this.
-Kees
--
Kees Cook
Chrome OS Security
On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter
wrote:
> On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote:
>> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
>>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
>>> > It is possible to wra
ong symbols to have non-zero offsets, but I must be
misunderstanding something here.
-Kees
>
> Put this somewhere to test. It fails for x86_64, too:
>
> diff --git a/init/main.c b/init/main.c
> index 61b993767db5..c9e0195c792a 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>
> ftrace_init();
>
> + {
> + extern void __attribute__((weak)) nonexistent_fn(void);
> + printk("nonexistent_fn = %p\n", nonexistent_fn);
> + BUG_ON(nonexistent_fn != NULL);
> + }
> +
> /* Do the rest non-__init'ed, we're now alive */
> rest_init();
> }
>
> Cheers,
> Rusty.
--
Kees Cook
Chrome OS Security
On Tue, Jan 6, 2015 at 2:58 PM, Rusty Russell wrote:
> Kees Cook writes:
>> On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell
>> wrote:
>>> Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
>>> section for weak symbols. These should not be re
2 @@ asmlinkage __visible void __init start_kernel(void)
>
> ftrace_init();
>
> + {
> + extern void __attribute__((weak)) nonexistent_fn(void);
> + printk("nonexistent_fn = %p\n", nonexistent_fn);
> + BUG_ON(nonexistent_fn != NULL);
> + }
> +
> /* Do the rest non-__init'ed, we're now alive */
> rest_init();
> }
Hm, I can't reproduce this on v3.19-rc4. My nonexistent_fn comes back
NULL regardless of CONFIG and kaslr on/off states I've tried. Could
this be a (yet another) linker bug? What was the toolchain used? I
built with gcc 4.8.2 and binutils 2.24.
-Kees
--
Kees Cook
Chrome OS Security
se values even from the root user, so I
would prefer this stays as-is.
Sorry I'm being dense, but what problem is %pK causing here? I'd be
happy to help get it fixed.
-Kees
--
Kees Cook
ChromeOS Security
On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings wrote:
> On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
>> On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings
>> wrote:
>> > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
>> > lea
aik (and I've done quite some code history checking) the proc files are
> not relied upon by userspace (up to about 10 years back). Patch to kill
> them all is pending and should hit either 3.3 or 3.4.
That works too. :)
--
Kees Cook
ChromeOS Security
In the continuing effort to avoid kernel addresses leaking to unprivileged
users, this patch switches to %pK for /proc/dri/*/vma.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_info.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_info.c b
Hi Corbin,
On Sat, Feb 12, 2011 at 10:13:04AM -0800, Corbin Simpson wrote:
> On Fri, Feb 11, 2011 at 7:29 PM, Kees Cook wrote:
> > In the continuing effort to avoid kernel addresses leaking to unprivileged
> > users, this patch switches to %pK for /proc/dri/*/vma.
>
Fix potential crashes due to use-before-NULL situations.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_fb_helper.c |3 ++-
drivers/media/video/em28xx/em28xx-video.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
it seemed best to put them all in
a single patch rather than chopping them up per maintainer.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
arch/arm/mach-omap2/board-n8x0.c | 2 +-
arch/mips/dec/prom/init.c | 6 +++---
arch/mip
On Thu, Apr 6, 2017 at 1:48 AM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Thu, 06 Apr 2017, Kees Cook <keesc...@chromium.org> wrote:
>> While examining output from trial builds with -Wformat-security enabled,
>> many strings were found that should be defin
On Thu, Jul 27, 2017 at 6:43 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
>> designated initializers&qu
On Fri, Jul 28, 2017 at 2:13 AM, Christian König
<christian.koe...@amd.com> wrote:
> Am 28.07.2017 um 03:43 schrieb Alex Deucher:
>>
>> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>>>
>>> As done for vega10 in
.@amd.com>
Cc: Hawking Zhang <hawking.zh...@amd.com>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
you think this is worth landing for v4.13, in which ca
d probably fold this change into my rst-ification of
Documentation/security/
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/rst
Specifically, the new Documentation/security/LSM.rst was rather short.
I think your lsm.txt and this one could be likely merged.
-Kees
--
On Sun, May 14, 2017 at 3:00 PM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Em Sun, 14 May 2017 14:05:09 -0700
> Kees Cook <keesc...@chromium.org> escreveu:
>
>> On Sun, May 14, 2017 at 8:38 AM, Mauro Carvalho Chehab
>> <mche...@s-opensource.co
sts.freedesktop.org
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callback argument type") in v4.14-rc3, but should be otherwise
stand-alone.
---
drivers/gpu/
On Thu, Oct 5, 2017 at 6:45 AM, Joonas Lahtinen
<joonas.lahti...@linux.intel.com> wrote:
> On Wed, 2017-10-04 at 17:54 -0700, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_s
c: Christian Gmeiner <christian.gmei...@gmail.com>
Cc: David Airlie <airl...@linux.ie>
Cc: etna...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +++
1 file changed, 3 inser
David Airlie <airl...@linux.ie>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Oscar Mateo <oscar.ma...@intel.com>
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@list
timer_list, not struct pxa3xx_gcu_priv.
Cc: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
Cc: "Gustavo A. R. Silva" <gust...@embeddedor.com>
Cc: Himanshu Jha <himanshujha199...@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-of
On Thu, Nov 9, 2017 at 9:08 AM, Bartlomiej Zolnierkiewicz
<b.zolnier...@samsung.com> wrote:
> On Tuesday, October 24, 2017 08:20:26 AM Kees Cook wrote:
>
>> diff --git a/drivers/video/fbdev/pxa3xx-gcu.c
>> b/drivers/video/fbdev/pxa3xx-gcu.c
>> index 933
nit_module+0xc0/0xd0
>> > >> [7.814318] __sys_trace_return+0x0/0x4
>> > >> [7.814325] ---[ end trace 3348554eb91e19a1 ]---
>> > >
>> > > Looks like I didn't test this code with CONFIG_REFCOUNT_FULL enabled :-/.
>> > &
On Mon, Nov 13, 2017 at 5:45 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> On Tue, Oct 24, 2017 at 08:20:26AM -0700, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_s
On Mon, Oct 30, 2017 at 4:49 PM, Eric Anholt <e...@anholt.net> wrote:
> Kees Cook <keesc...@chromium.org> writes:
>
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and fro
On Tue, Oct 31, 2017 at 3:18 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Mon, Oct 30, 2017 at 03:05:29PM -0700, Kees Cook wrote:
>> On Mon, Oct 30, 2017 at 3:08 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
>> > On Tue, Oct 24, 2017 at 08:16:09AM -0700, Kees Co
trand.net>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/dr
On Fri, Dec 8, 2017 at 2:17 AM, David Laight <david.lai...@aculab.com> wrote:
> From: Kees Cook
>> Sent: 06 December 2017 20:29
>>
>> There's no good reason to separate the access_ok() from the copy,
>> especially since the access_ok() size is hard-coded instead of
On Wed, Oct 25, 2017 at 4:16 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Quoting Kees Cook (2017-10-25 15:05:13)
>> On Wed, Oct 25, 2017 at 3:11 PM, Chris Wilson <ch...@chris-wilson.co.uk>
>> wrote:
>> > Quoting Chris Wilson (2017-10-25 11:24:19)
>&
On Wed, Oct 25, 2017 at 3:11 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Quoting Chris Wilson (2017-10-25 11:24:19)
>> Quoting Chris Wilson (2017-10-24 17:17:09)
>> > Quoting Kees Cook (2017-10-24 16:13:44)
>> > > In preparation for unconditionally p
c: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/gpu/drm/gma500/psb_lid.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_lid.c b/drivers/gpu/drm/gma500/psb_lid.c
index 1d2ebb5e530f..b
lv...@suse.de>
Cc: Hans de Goede <hdego...@redhat.com>
Cc: "Gustavo A. R. Silva" <gust...@embeddedor.com>
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers
edesktop.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/gpu/drm/vc4/vc4_bo.c | 9 +++--
drivers/gpu/drm/vc4/vc4_gem.c | 10 --
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
l.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: David Airlie <airl...@linux.ie>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook <
On Mon, Oct 30, 2017 at 3:08 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Tue, Oct 24, 2017 at 08:16:09AM -0700, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_s
s(+), 4 deletions(-)
>>
>> Reviewed-by: Thierry Reding <tred...@nvidia.com>
> Thanks everyone. I've taken the patch in my tree.
Hi!
Just checking in on this -- I don't see this patch in linux-next. Is
this queued somewhere else?
Thanks!
-Kees
--
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, May 23, 2018 at 5:36 PM, Ben Skeggs <bske...@redhat.com> wrote:
> On Thu, May 24, 2018 at 8:48 AM, Kees Cook <keesc...@chromium.org> wrote:
>> On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> On Thu, Mar 15, 2018 at 7:05 PM,
On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeg...@gmail.com> wrote:
>> On 14 March 2018 at 21:08, Thierry Reding <thierry.red...@gmail.com> wrote:
>>> On Tue, Mar 13, 2018 at 11:24:1
-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
.../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
.../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
2 files changed, 37 insertions(+), 4 deletions(-)
diff
8/3/7/621
>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
Reviewed-by: Kees Cook <keesc...@chromium.org>
Daniel, can this go via you, or what's the best path for this patch?
Thanks!
-Kees
> ---
> This was a little hard to figure out but I think 32 should be a
> co
ange is bounded by
> the size buffer passed to hdmi_infoframe_pack which is a fixed size.
> Switch to this upper bound.
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
Reviewed-by: Kees Cook <keesc...@chromium.org>
Sam
sues in some places, maybe it is totally fine.
Okay, thanks! Who can take the patch into their tree?
-Kees
--
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst wrote:
> On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> allocates the working buffers before starting the writing so it won't
>> abort in the middle.
In the quest to remove all stack VLA usage from the kernel[1], this
uses the maximum sane buffer size and removes copy/paste code.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/gpu/drm/amd/amdgpu
In the quest to remove all stack VLA usage from the kernel[1], this
sets the buffer to maximum size and adds a sanity check.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i2c/tda9950.c | 5 -
1
On Thu, May 24, 2018 at 10:24 AM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the working buffers before starting the writing so it won't
> abort in the middle. This needs an initial walk of the lists to figure
> out how larg
On Tue, Jun 26, 2018 at 1:21 PM, Joe Perches wrote:
> On Tue, 2018-06-26 at 10:40 -0700, Kees Cook wrote:
>> This is the patch I've got prepared now that fixes for all VLAs have been
>> sent to maintainers (some are still under review/adjustment, but there
>> aren't any unexp
which
are explicitly checking that VLAs trigger their respective tests.
Signed-off-by: Kees Cook
---
Makefile | 3 +++
drivers/gpu/drm/i915/Makefile | 2 +-
lib/Makefile | 2 ++
scripts/Makefile.extrawarn| 1 -
4 files changed, 6 insertions(+), 2 deletions
In the quest to remove all stack VLA usage from the kernel[1], this
switches to using a kasprintf()ed buffer. Return paths are updated
to free the allocation.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers
1 - 100 of 627 matches
Mail list logo
