fix, new commit messages]
Signed-off-by: Kees Cook
---
drivers/scsi/esas2r/esas2r_init.c | 2 +-
drivers/scsi/esas2r/esas2r_ioctl.c | 2 +-
drivers/scsi/esas2r/esas2r_log.h | 4 ++--
drivers/scsi/esas2r/esas2r_main.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a
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/scs
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/block/cc
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/scsi/h
On Wed, Dec 21, 2016 at 12:33 AM, Christoph Hellwig wrote:
> On Fri, Dec 16, 2016 at 05:05:15PM -0800, Kees Cook wrote:
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using designated initializers. These were identified during
>&
fix, new commit messages]
Signed-off-by: Kees Cook
---
v2:
- fix %lu to %zu on sizeof() values, bart
---
drivers/scsi/esas2r/esas2r_init.c | 2 +-
drivers/scsi/esas2r/esas2r_ioctl.c | 2 +-
drivers/scsi/esas2r/esas2r_log.h | 4 ++--
drivers/scsi/esas2r/esas2r_main.c | 4 ++--
4 files changed, 6
tly so the
variables can all be const.
Inspired by similar changes in grsecurity/PaX.
Signed-off-by: Kees Cook
---
Documentation/cdrom/cdrom-standard.tex | 9 +-
drivers/block/paride/pcd.c | 2 +-
drivers/cdrom/cdrom.c | 58 --
dri
This makes sure format strings cannot leak into the printk call via the
constructed buffer.
Signed-off-by: Kees Cook
---
drivers/scsi/esas2r/esas2r_log.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/esas2r/esas2r_log.c b/drivers/scsi/esas2r/esas2r_log.c
if (kioc->data_dir & UIOC_WR) {
> + if (pthru32->dataxferlen > kioc->xferlen)
> + return -EINVAL;
> if (copy_from_user(kioc->buf_vaddr, kioc->user_data,
> pthru32-&
This makes sure format strings cannot leak into the printk call via the
constructed buffer.
Signed-off-by: Kees Cook
---
drivers/scsi/esas2r/esas2r_log.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/esas2r/esas2r_log.c b/drivers/scsi/esas2r/esas2r_log.c
On Tue, Dec 17, 2013 at 12:00 PM, Greg Kroah-Hartman
wrote:
> On Tue, Dec 17, 2013 at 10:27:33AM -0800, Kees Cook wrote:
>> This makes sure format strings cannot leak into the printk call via the
>> constructed buffer.
>>
>> Signed-off-by: Kees Cook
>> ---
>
On Tue, Dec 17, 2013 at 9:42 PM, Joe Perches wrote:
> On Tue, 2013-12-17 at 10:27 -0800, Kees Cook wrote:
>> This makes sure format strings cannot leak into the printk call via the
>> constructed buffer.
> []
>> diff --git a/drivers/scsi/esas2r/esas2r_log.c
>> b/dr
This makes sure format strings cannot leak into the printk call via the
constructed buffer.
Signed-off-by: Kees Cook
Acked-by: Bradley Grove
---
v2:
- add newline via printk instead.
---
drivers/scsi/esas2r/esas2r_log.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff
->dataxferaddr = kioc->buf_paddr;
>> if (kioc->data_dir & UIOC_WR) {
>>+ if (pthru32->dataxferlen > kioc->xferlen)
>>+ return -EINVAL;
>> if (copy_from_user(kioc->buf_vaddr, kioc->user_data,
>>
On Thu, Jan 9, 2014 at 11:53 AM, Saxena, Sumit wrote:
>
>
>>-Original Message-----
>>From: Kees Cook [mailto:keesc...@google.com]
>>Sent: Friday, January 10, 2014 12:05 AM
>>To: Saxena, Sumit
>>Cc: Dan Carpenter; DL-MegaRAID Linux; James E.J. Bottomley;
ing
cache-managed memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
dri
ing
cache-managed memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
dri
ctions = sizeof(critical_sections)
> - / sizeof(*critical_sections);
> +#define NUM_CRITICAL_SECTIONS 14
The compiler doesn't treat "const" as a literal, hence the need to
change this. However, you can still use the sizeof (actually, this is
exactly ARRAY_SIZE()). Perhaps:
#define NUM_CRITICAL_SECTIONS ARRAY_SIZE(critical_sections)
?
Otherwise, looks great!
-Kees
--
Kees Cook
Pixel Security
r. Replace the array
> sizes with a pre-processor-level constant instead using ARRAY_SIZE.
>
> This was prompted by https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Stephen Kitt
Thanks!
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/aic7xxx/aic79xx_core.c
product of the
> size of an element and the number of elements, avoiding the VLA
> altogether.
>
> This was prompted by https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Stephen Kitt
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/bfa/bfad_bsg.c | 2 +-
>
? If the latter, please resend
> this when those changes are in, thanks.
It's in -next currently ("locking/refcount: Create unchecked atomic_t
implementation")
-Kees
--
Kees Cook
Pixel Security
aged
memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/s
On Mon, Aug 28, 2017 at 2:42 PM, Bart Van Assche wrote:
> On Mon, 2017-08-28 at 14:34 -0700, Kees Cook wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index f6097b89d5d3..f1c6bd56dd5b 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/s
On Tue, Sep 11, 2018 at 11:15 AM, Laura Abbott wrote:
> While reviewing another part of the code, Kees noticed that the
> strncpy of the partition name might not always be NUL terminated. Switch
> to using strlcpy which does this safely.
>
> Reported-by: Kees Cook
> Signed-of
trncat' specified
> bound 64 equals destination size [-Werror=stringop-overflow=]
> strncat(vscsi->eye, vdev->name, MAX_EYE);
> ^~~~
>
> Switch to a single snprintf instead of a strcpy + strcat to handle this
> cleanly.
>
> Si
On Tue, Sep 11, 2018 at 11:24 AM, Kees Cook wrote:
> On Tue, Sep 11, 2018 at 11:05 AM, Laura Abbott wrote:
>>
>> There's currently a warning about string overflow with strncat:
>>
>> drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis
On Tue, Sep 11, 2018 at 12:22 PM, Laura Abbott wrote:
>
> While reviewing another part of the code, Kees noticed that the
> strncpy of the partition name might not always be NUL terminated. Switch
> to using strscpy which does this safely.
>
> Reported-by: Kees Cook
> Signed
On Wed, Oct 31, 2018 at 9:19 PM, Souptick Joarder wrote:
> Replaced dma_pool_alloc + memset with dma_pool_zalloc
>
> Signed-off-by: Brajeswar Ghosh
> Signed-off-by: Souptick Joarder
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +--
&g
vers/net/ethernet/sun/sunhme.c | 4 ++--
> drivers/scsi/qlogicpti.h | 2 +-
> fs/notify/inotify/inotify_user.c | 2 +-
> kernel/irq/timings.c | 2 +-
> lib/vsprintf.c| 2 +-
> net/core/skbuff.c | 2 +-
> 17 files changed, 33 insertions(+), 31 deletions(-)
>
> --
> 2.19.1
>
--
Kees Cook
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
---
This has been up
which will be zero-filled,
instead of undesignated NULLs.
Signed-off-by: Kees Cook
---
drivers/scsi/qedf/qedf_debugfs.c | 2 +-
drivers/scsi/qedi/qedi_debugfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qedf/qedf_debugfs.c b/drivers/scsi/qedf/qedf_debu
On Thu, Mar 30, 2017 at 1:18 AM, Christoph Hellwig wrote:
> On Wed, Mar 29, 2017 at 01:55:09PM -0700, Kees Cook wrote:
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using designated initializers. These were identified during
>&
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. This also initializes the
array members using the enum used to look up __port_action entries.
Signed-off-by: Kees Cook
---
v3:
- drop bfa_module_s changes, since that has
that trades
coverage for speed, and checks only the overflow condition. This gets
us the critical coverage without the changes in performance. This is
basically what PaX/grsecurity already did: there is a tiny change to
the atomic inc functions to detect the wrap.
-Kees
--
Kees Cook
Pixel Security
gging stuff is actually preventing
> the security improvement from being adopted, which is unfortunate.
We've been trying to handle the conflicting desires of those wanting
very precise refcounting implementation and gaining the security
protections. Ultimately, the best way forward seemed to be to first
land the precise refcounting implementation, and start conversion
until we ran into concerns over performance. Now, since we're here, we
can move forward with getting a fast implementation that provides the
desired security protections without too greatly messing with the
refcount API.
-Kees
--
Kees Cook
Pixel Security
On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley
wrote:
> On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
>> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers
>> wrote:
>> > > > Of course, having extra checks behind a debug option is fine.
>> > >
.
Cc: Daniel Micay
Signed-off-by: Kees Cook
---
drivers/scsi/qedf/qedf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
index cceddd995a4b..a5c97342fd5d 100644
--- a/drivers/scsi/qedf/qedf_main.c
+++ b/drivers
On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche
wrote:
> On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
>> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
>> index cceddd995a4b..a5c97342fd5d 100644
>> --- a/drivers/scsi/qedf/qedf_main.c
>&
by u16 and that
the DMA buffer was not overflowed. Fixes the size of mfa, which is not
FC_FDMI_PORT_ATTR_MAXFRAMESIZE_LEN (but it will be padded up to 4). This
was noticed by the future CONFIG_FORTIFY_SOURCE checks.
Cc: Daniel Micay
Signed-off-by: Kees Cook
---
drivers/scsi/csiostor
On Mon, May 22, 2017 at 8:05 AM, Varun Prakash wrote:
> On Tue, May 09, 2017 at 03:34:44PM -0700, Kees Cook wrote:
>> When copying attributes, the len argument was padded out and the resulting
>> memcpy() would copy beyond the end of the source buffer. Avoid this,
>> and u
trick of silently
expanding its allocation into the space the slab allocator has given
it? If not, this looks like a real bug.
What I don't see is how req->sense is _not_ at offset 0 in the
scsi_sense_cache object...
-Kees
--
Kees Cook
Pixel Security
ng? I'll try to
reproduce this on my end...
-Kees
--
Kees Cook
Pixel Security
On Wed, Apr 4, 2018 at 1:49 PM, Oleksandr Natalenko
wrote:
> Hi.
>
> On středa 4. dubna 2018 22:21:53 CEST Kees Cook wrote:
>>
>> ...
>> That means scsi_sense_cache should be 96 bytes in size? But a 22 byte
>> read starting at offset 94 happened? That seems like
On Thu, Apr 5, 2018 at 2:56 AM, Oleksandr Natalenko
wrote:
> Hi.
>
> 04.04.2018 23:25, Kees Cook wrote:
>>
>> Thanks for the report! I hope someone more familiar with sg_io() can
>> help explain the changing buffer offset... :P
>
>
> Also, FYI, I kept the serve
/sda; smartctl -a /dev/sdb ) > /dev/null;
done &
I assume I'm missing something from your .config, but since I don't
boot with an initramfs, I had to tweak it a bit. I'll try again...
-Kees
--
Kees Cook
Pixel Security
6f58f8891468aeba1ab2cc9f45668735
The thing I can't figure out is how req->sense is slipping forward in
(and even beyond!) the allocation.
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 9, 2018 at 12:02 PM, Oleksandr Natalenko
wrote:
>
> Hi.
>
> (fancy details for linux-block and BFQ people go below)
>
> 09.04.2018 20:32, Kees Cook wrote:
>>
>> Ah, this detail I didn't have. I've changed my environment to
>
On Mon, Apr 9, 2018 at 1:30 PM, Kees Cook wrote:
> Ah! dm-crypt too. I'll see if I can get that added easily to my tests.
Quick update: I added dm-crypt (with XFS on top) and it hung my system
almost immediately. I got no warnings at all, though.
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 9, 2018 at 11:35 PM, Oleksandr Natalenko
wrote:
> Did your system hang on smartctl hammering too? Have you got some stack
> traces to compare with mine ones?
Unfortunately I only had a single hang with no dumps. I haven't been
able to reproduce it since. :(
-Kees
--
On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :(
>
>
> For your conve
On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook wrote:
> I'll see about booting with my own kernels, etc, and try to narrow this down.
> :)
If I boot kernels I've built, I no longer hit the bug in this VM
(though I'll keep trying). What compiler are you using?
-Kees
--
Kees Cook
Pixel Security
On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook wrote:
> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook wrote:
>> I'll see about booting with my own kernels, etc, and try to narrow this
>> down. :)
>
> If I boot kernels I've built, I no longer hit the bug in this VM
&g
On Wed, Apr 11, 2018 at 5:03 PM, Kees Cook wrote:
> On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook wrote:
>> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook wrote:
>>> I'll see about booting with my own kernels, etc, and try to narrow this
>>> down. :)
>>
>&g
On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
wrote:
> Hi.
>
> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>> My first bisect attempt gave me commit 5448aca41cd5 ("null_blk: wire
>> up timeouts"), which seems insane given that null_blk isn&#x
On Thu, Apr 12, 2018 at 3:01 PM, Kees Cook wrote:
> On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
> wrote:
>> Hi.
>>
>> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>>> My first bisect attempt gave me commit 5448aca41cd5 ("null_blk: wire
On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook wrote:
> After fixing up some build issues in the middle of the 4.16 cycle, I
> get an unhelpful bisect result of commit 0a4b6e2f80aa ("Merge branch
> 'for-4.16/block'"). Instead of letting the test run longer, I'm
On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook wrote:
> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook wrote:
>> After fixing up some build issues in the middle of the 4.16 cycle, I
>> get an unhelpful bisect result of commit 0a4b6e2f80aa ("Merge branch
>> 'for-4.16/block&
On Mon, Apr 16, 2018 at 1:44 PM, Kees Cook wrote:
> On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook wrote:
>> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook wrote:
>>> After fixing up some build issues in the middle of the 4.16 cycle, I
>>> get an unhelpful bisect result of
ic place to watch in the kernel for the corruption, though, that
might help. If I get stuck again today, I'll try it.
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 3:02 AM, James Bottomley
wrote:
> On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
>> I still haven't figured this out, though... any have a moment to look
>> at this?
>
> Just to let you know you're not alone ... but I can't make a
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901inc_in_
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901inc_in_
On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook wrote:
> The above bfq_dispatch_request+0x99/0xad0 is still
> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KASAN
> removed. 0x99 is 153 decimal:
>
> (gdb) disass bfq_dispatch_request
> Dump of assembler
On Tue, Apr 17, 2018 at 1:20 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook wrote:
>> The above bfq_dispatch_request+0x99/0xad0 is still
>> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KASAN
>> removed. 0x99 is 153 decima
t_request() get called without bfq_prepare_request() being
called first?
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote:
> I see elv.priv[1] assignments made in a few places -- is it possible
> there is some kind of uninitialized-but-not-NULL state that can leak
> in there?
Got it. This fixes it for me:
diff --git a/block/blk-mq.c b/block/blk-m
Reported-by: Oleksandr Natalenko
Fixes: bd166ef183c26 ("blk-mq-sched: add framework for MQ capable IO
schedulers")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
In theory, BFQ needs to also check the RQF_ELVPRIV flag, but I'll leave that
to Paolo to figure out. Also, my Fixe
On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
> On 4/17/18 3:25 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote:
>>> I see elv.priv[1] assignments made in a few places -- is it possible
>>> there is some kind of uninitialized-but-not-NULL
On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe wrote:
> On 4/17/18 3:42 PM, Kees Cook wrote:
>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>> may attempt to read rq->elv fields. When requests got reused, this
>> caused BFQ to think it alr
On Tue, Apr 17, 2018 at 3:57 PM, Jens Axboe wrote:
> On 4/17/18 3:48 PM, Jens Axboe wrote:
>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
>>>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>>>> On Tue, Apr 17
t;what". :) If you want, grab
the reproducer VM linked to earlier in this thread; it'll hit the
problem within about 30 seconds of running the reproducer.
-Kees
--
Kees Cook
Pixel Security
=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/scsi/dpt_i2o.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 5ceea8da7bb6..37de8fb186d7 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers
kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/scsi/osd/osd_initiator.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
ind
://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/scsi/ufs/ufshcd.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index
er 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
gt; 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 consider the
whole series:
Reviewed-by: Kees Cook
Thanks!
-Kees
--
Kees Cook
Pixel Security
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez 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 wrote:
>> > + This used to be the default firmware loading facility, and udev
>> > us
On Wed, May 2, 2018 at 3:21 PM, Kees Cook wrote:
> On the quest to remove all VLAs from the kernel[1] this moves the sg_list
> variable off the stack, as already done for other allocated buffers in
> adpt_i2o_passthru(). Additionally consolidates the error path for kfree().
>
&g
dable to distinguish between "sense" meaning "struct request_sense"
and "sshdr" meaning "struct scsi_sense_hdr".
Signed-off-by: Kees Cook
---
drivers/block/pktcdvd.c| 36 ++--
drivers/cdrom/cdrom.c | 22 +++-
Instead of dynamically allocating the sense buffers, put them on the
stack so that future compile-time sizeof() checks will be able to see
their buffer length.
Signed-off-by: Kees Cook
---
drivers/ata/libata-scsi.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff
those 96 bytes onto the stack to avoid triggering
the sizeof() check.
Signed-off-by: Kees Cook
---
drivers/scsi/scsi_lib.c| 6 +++---
include/scsi/scsi_device.h | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.
This removes the unused sense buffer in read_cap16() and write_same16().
Signed-off-by: Kees Cook
---
drivers/scsi/cxlflash/superpipe.c | 8 ++--
drivers/scsi/cxlflash/vlun.c | 7 ++-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxlflash/superpipe.c
This is a follow-up to commit f7068114d45e ("sr: pass down correctly
sized SCSI sense buffer") which further cleans up and removes needless
sense character array buffers and "struct request_sense" usage in favor
of the common "struct scsi_sense_hdr".
First, drop a bunch of unused sense buffers:
[
Both SCSI and ATAPI share the sense header. In preparation for using the
struct scsi_sense_hdr more widely, move this into a separate header and
move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE
by way of CONFIG_BLK_SCSI_REQUEST.
Signed-off-by: Kees Cook
---
block
This drops unused sense buffers from:
cdrom_eject()
cdrom_read_capacity()
cdrom_read_tocentry()
ide_cd_lockdoor()
ide_cd_read_toc()
Signed-off-by: Kees Cook
---
drivers/ide/ide-cd.c | 36 +++-
drivers/ide/ide-cd.h
On Tue, May 22, 2018 at 11:50 AM, Martin K. Petersen
wrote:
>
> Christoph,
>
>> On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote:
>>> Both SCSI and ATAPI share the sense header. In preparation for using the
>>> struct scsi_sense_hdr more widely, mov
ut
>> everyone else, and keep the scsi code where it belongs.
>
> Fine with me then, hopefully we can some day kill it off.
I'll send a v2. I found a few other things to fix up (including the
cdrom.c one).
Thanks!
-Kees
--
Kees Cook
Pixel Security
On Tue, May 22, 2018 at 4:34 PM, Randy Dunlap wrote:
> On 05/22/2018 04:31 PM, Kees Cook wrote:
>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe w
On Tue, May 22, 2018 at 4:42 PM, Jens Axboe wrote:
> On May 22, 2018, at 5:31 PM, Kees Cook wrote:
>>
>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>>> On Tue, May 22, 2018 at 01:09:41PM
t,
> mostly getting rid of the entire stack dependency.
Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile:
obj-$(CONFIG_SCSI) += scsi/
So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's
scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll
still need to move the code from drivers/scsi/ to block/. Is this
okay?
-Kees
--
Kees Cook
Pixel Security
On Wed, May 23, 2018 at 1:25 AM, Sergei Shtylyov
wrote:
> Hello!
>
> On 5/22/2018 9:15 PM, Kees Cook wrote:
>
>> To avoid introducing problems like those fixed in commit f7068114d45e
>> ("sr: pass down correctly sized SCSI sense buffer"), this creates a macro
put the function in there originally.
Honestly, it's almost so small I could make it a static inline. :P
> I'm traveling today so I probably won't get a chance to look closely
> until tomorrow morning.
No worries; thanks for looking at it!
-Kees
--
Kees Cook
Pixel Security
s' series?
>
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup
Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in
weird config cases?
Otherwise, yeah, looks good to me. Thanks!
-Kees
--
Kees Cook
Pixel Security
er.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/aic7xxx/aic79xx.h | 5 +
drivers/scsi/aic7xxx/aic79xx_core.c | 29 -
2 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic79xx.h b/drivers/scsi/aic7xxx/aic79xx.
There was a seemingly missing call to setup_timer() in one handler,
so add setup_timer() here to remove the open-coded initialization.
Cc: qlogic-storage-upstr...@qlogic.com
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kee
: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: net...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Kees Cook
---
drivers/net/irda/bfin_sir.c | 5 +++--
drivers/scsi/ibmvscsi/ibmvfc.c | 14 ++
d
red due to the earlier
call to mpt_free_fw_memory()...
-Kees
> ///--->newFwSize can control in userspace
> printk(MYIOC_s_ERR_FMT "%s@%d::mptctl_replace_fw - "
> "Unable to read in mpt_ioctl_replace_fw image "
> "@ %p\n", ioc->name, __FILE__, __LINE__, uarg);
> mpt_free_fw_memory(ioc);
> return -EFAULT;
> }
>
> ..
>
> return 0;
> }
-Kees
--
Kees Cook
Pixel Security
aged
memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/s
: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: net...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Kees Cook
Acked-by: Tyrel Datwyler # for ibmvscsi
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 ++
d
er.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/aic7xxx/aic79xx.h | 5 +
drivers/scsi/aic7xxx/aic79xx_core.c | 29 -
2 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic79xx.h b/drivers/scsi/aic7xxx/aic79xx.
1 - 100 of 163 matches
Mail list logo
