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 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:
[
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
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
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
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
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 direct
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.20-rc1&id=6c3b7af1c975b87b86dcb2af233d1ae21eb05107
>
> [2]
> https://github.com/anthraxx/linux-hardened/commit/9460692de8eb53fd62d59f564eba215e7c03a34b
>
> [3] https://lwn.net/Articles/763641/
>
> [4] https://outflux.net/slides/2018/lss/danger.pdf
--
Kees Cook
On Wed, Nov 14, 2018 at 6:06 PM, Omar Sandoval wrote:
> On Wed, Nov 14, 2018 at 05:23:06PM -0600, Kees Cook wrote:
>> On Sat, Nov 10, 2018 at 8:15 AM, Jordan Glover
>> wrote:
>> > Hello,
>> >
>> > Commit 6c3b7af1c975b87b86dcb2af233d1ae21eb05107 ("
9209ef40
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e00c2f40
#syz fix: blk-mq: protect debugfs_create_files() from failures
--
Kees Cook
On Thu, May 30, 2019 at 05:00:48PM -0700, Bart Van Assche wrote:
> Commit e99e88a9d2b0 renamed a function argument without updating the
> corresponding kernel-doc header. Update the kernel-doc header.
>
> Cc: Kees Cook
> Fixes: e99e88a9d2b0 ("treewide: setup_timer() ->
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.
>> > >
? 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
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Matias Bjorling
Cc: linux-block@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/lightnvm/pblk
Cc: Vladimir Davydov
Cc: Matthew Wilcox
Cc: Jeff Layton
Cc: linux-block@vger.kernel.org
Cc: linux...@kvack.org
Cc: Thomas Gleixner
Signed-off-by: Kees Cook
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callback argument type") in v4.14-rc3, but should be
On Thu, Oct 5, 2017 at 7:56 AM, Jens Axboe wrote:
> On 10/04/2017 06:49 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> to pass the tim
sions would have to wait until
4.16. With most conversions only depending on the new API, it seemed
silly to wait another whole release when the work is just waiting to
be merged.
But yes, timing was not ideal. I did try to get it in earlier, but I
think tglx was busy with other concerns.
-Kees
--
g Kees will respin the writeback/laptop version and I can shove
> that in there too.
Thanks for setting this up! I'll respin and send it out again.
-Kees
--
Kees Cook
Pixel Security
ned-off-by: Kees Cook
---
v2: Rebased to linux-block.git/for-4.15/timer
---
drivers/block/aoe/aoecmd.c | 6 +++---
drivers/block/aoe/aoedev.c | 9 +++--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index dc43254e05a4..55
Cc: Vladimir Davydov
Cc: Matthew Wilcox
Cc: Jeff Layton
Cc: linux-block@vger.kernel.org
Cc: linux...@kvack.org
Cc: Thomas Gleixner
Signed-off-by: Kees Cook
---
v2: Rebased to linux-block.git/for-4.15/timer
---
block/blk-core.c | 10 +-
include/linux/writeback.h | 2 +-
mm
On Fri, Oct 6, 2017 at 7:19 AM, Jens Axboe wrote:
> On 10/05/2017 05:13 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> to pass the tim
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
>
es" tag that Linus merged after the block changes:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
>>>> tags/for-4.17/dm-changes
>>>>
>>>> # ./check tests/generic/347
>>>> FSTYP -- ext4
>>
o finish all async __init code before freeing the memory */
async_synchronize_full();
--
Kees Cook
Pixel Security
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
s, we can
> now use the new struct_size() helper:
>
> instance = kmalloc(struct_size(instance, iov, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
-Kees
> ---
>
-a...@arndb.de/
> Signed-off-by: Arnd Bergmann
Reviewed-by: Kees Cook
-Kees
> ---
> v2:
> - don't try to zero a NULL descriptor pointer,
> based on review from Roland Kammerer.
> ---
> drivers/block/drbd/drbd_receiver.c | 14 --
> 1 file changed, 12 inserti
:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kerne
->op = req_op(cmd->rq);
__entry->zone_no = zone_no;
__entry->zone_cond = zone_cond;
__assign_disk_name(__entry->disk, cmd->rq->q->disk);
),
This should probably have been a dynamic string, but it's not. So let's
make sure this stays padded. Can you send this again but use
strscpy_pad() instead?
--
Kees Cook
Cc: linux-block@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/block/drbd/drbd_int.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index a30a5ed811be..7eecc53fae3d 100644
--- a/drivers/block/drbd/drbd_int.h
+++
:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kerne
gt; | }
>
> From the above, we need both 1) a NUL-terminated string and 2) a
> NUL-padded string. So, let's use strscpy_pad() as per Kees' suggestion
> from v1.
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-str
On Fri, 15 Sep 2023 13:03:16 -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
>
:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kerne
urn ret;
> | }
>
> >From the above, we need both 1) a NUL-terminated string and 2) a
> NUL-padded string. So, let's use strscpy_pad() as per Kees' suggestion
> from v1.
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminate
onditionally check for truncation (as was already done
for the case where "%SESSNAME%" was present).
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312100355.lhojpgky-...@intel.com/
Cc: "Md. Haris Iqbal"
Cc: Jack Wang
Cc: Jens Axboe
Cc: linux-block
From: Navid Emamdoost
nla_nest_start() may fail and return NULL. Insert a check and set errno
based on other call sites within the same source code.
Signed-off-by: Navid Emamdoost
Reviewed-by: Michal Kubecek
Fixes: 47d902b90a32 ("nbd: add a status netlink command")
Signed-off-by:
72 matches
Mail list logo
