All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Christoph Hellwig <hch@lst.de>,
	kernel test robot <oliver.sang@intel.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <bvanassche@acm.org>,
	John Garry <john.garry@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, lkp@intel.com, linux-mm@kvack.org,
	linux-hardening@vger.kernel.org
Subject: Re: [scsi]  6aded12b10: kernel_BUG_at_mm/usercopy.c
Date: Wed, 23 Mar 2022 15:42:34 +0000	[thread overview]
Message-ID: <Yjs/6pLB1uDKBRCG@casper.infradead.org> (raw)
In-Reply-To: <202203230809.D63BF9511@keescook>

On Wed, Mar 23, 2022 at 08:40:30AM -0700, Kees Cook wrote:
> On Wed, Mar 23, 2022 at 08:14:10AM +0100, Christoph Hellwig wrote:
> > The actual warning is;
> > 
> > [   34.496096][  T331] usercopy: Kernel memory overwrite attempt detected to spans multiple pages (off set 0, size 6)!
> > 
> > This is for the cmnd field in struct scsi_cmnd, which is allocated by
> > the block layer as part of the request allocator.  So with a specific
> > packing it can legitimately span pages.
> > 
> > Kees: how can we annotate that this is ok?
> 
> The main problem is that CONFIG_HARDENED_USERCOPY_PAGESPAN=y is broken
> (and nothing should be setting it).
> 
> This series removes it:
> https://lore.kernel.org/linux-hardening/20220110231530.665970-1-willy@infradead.org/
> 
> Matthew, what's the status of that series? Will it make the current
> merge window?

I thought you were going to merge it!  I haven't put it in any of my
public trees.

> As for the SCSI changes, I'm a bit worried about type confusion, as I
> don't see anything actually validating types/sizes when converting:
> 
> static inline void *blk_mq_rq_to_pdu(struct request *rq)
> {
>         return rq + 1;
> }
> 
> But I guess that ship has sailed. :P
> 
> Regardless, I'm concerned that disabling PAGESPAN will just uncover
> further checks, though. Where is allocation happening? The check is here:
> 
> static int scsi_fill_sghdr_rq(struct scsi_device *sdev, struct request *rq,
>                 struct sg_io_hdr *hdr, fmode_t mode)
> {
>         struct scsi_cmnd *scmd = blk_mq_rq_to_pdu(rq);
> 
>         if (hdr->cmd_len < 6)
>                 return -EMSGSIZE;
>         if (copy_from_user(scmd->cmnd, hdr->cmdp, hdr->cmd_len))
>                 return -EFAULT;
> 	...
> }
> 
> I don't see any earlier marking for this copy_from_user(), so I assume
> the old allocation was a plain kmalloc().
> 
> For comparision, a related marking can be seen for a copy_to_user() case
> in commit 0afe76e88c57 ("scsi: Define usercopy region in scsi_sense_cache
> slab cache")
> 
> I *think* the allocation is happening in scsi_ioctl_reset()? But that's
> a plain kmalloc(), so I'm not sure why PAGESPAN would have tripped...
> are there other allocation paths?
> 
> -- 
> Kees Cook
> 

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: lkp@lists.01.org
Subject: Re: [scsi] 6aded12b10: kernel_BUG_at_mm/usercopy.c
Date: Wed, 23 Mar 2022 15:42:34 +0000	[thread overview]
Message-ID: <Yjs/6pLB1uDKBRCG@casper.infradead.org> (raw)
In-Reply-To: <202203230809.D63BF9511@keescook>

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

On Wed, Mar 23, 2022 at 08:40:30AM -0700, Kees Cook wrote:
> On Wed, Mar 23, 2022 at 08:14:10AM +0100, Christoph Hellwig wrote:
> > The actual warning is;
> > 
> > [   34.496096][  T331] usercopy: Kernel memory overwrite attempt detected to spans multiple pages (off set 0, size 6)!
> > 
> > This is for the cmnd field in struct scsi_cmnd, which is allocated by
> > the block layer as part of the request allocator.  So with a specific
> > packing it can legitimately span pages.
> > 
> > Kees: how can we annotate that this is ok?
> 
> The main problem is that CONFIG_HARDENED_USERCOPY_PAGESPAN=y is broken
> (and nothing should be setting it).
> 
> This series removes it:
> https://lore.kernel.org/linux-hardening/20220110231530.665970-1-willy(a)infradead.org/
> 
> Matthew, what's the status of that series? Will it make the current
> merge window?

I thought you were going to merge it!  I haven't put it in any of my
public trees.

> As for the SCSI changes, I'm a bit worried about type confusion, as I
> don't see anything actually validating types/sizes when converting:
> 
> static inline void *blk_mq_rq_to_pdu(struct request *rq)
> {
>         return rq + 1;
> }
> 
> But I guess that ship has sailed. :P
> 
> Regardless, I'm concerned that disabling PAGESPAN will just uncover
> further checks, though. Where is allocation happening? The check is here:
> 
> static int scsi_fill_sghdr_rq(struct scsi_device *sdev, struct request *rq,
>                 struct sg_io_hdr *hdr, fmode_t mode)
> {
>         struct scsi_cmnd *scmd = blk_mq_rq_to_pdu(rq);
> 
>         if (hdr->cmd_len < 6)
>                 return -EMSGSIZE;
>         if (copy_from_user(scmd->cmnd, hdr->cmdp, hdr->cmd_len))
>                 return -EFAULT;
> 	...
> }
> 
> I don't see any earlier marking for this copy_from_user(), so I assume
> the old allocation was a plain kmalloc().
> 
> For comparision, a related marking can be seen for a copy_to_user() case
> in commit 0afe76e88c57 ("scsi: Define usercopy region in scsi_sense_cache
> slab cache")
> 
> I *think* the allocation is happening in scsi_ioctl_reset()? But that's
> a plain kmalloc(), so I'm not sure why PAGESPAN would have tripped...
> are there other allocation paths?
> 
> -- 
> Kees Cook
> 

  reply	other threads:[~2022-03-23 15:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-20 14:34 [scsi] 6aded12b10: kernel_BUG_at_mm/usercopy.c kernel test robot
2022-03-20 14:34 ` kernel test robot
2022-03-23  7:14 ` Christoph Hellwig
2022-03-23  7:14   ` Christoph Hellwig
2022-03-23 15:40   ` Kees Cook
2022-03-23 15:40     ` Kees Cook
2022-03-23 15:42     ` Matthew Wilcox [this message]
2022-03-23 15:42       ` Matthew Wilcox
2022-03-23 22:30       ` Kees Cook
2022-03-23 22:30         ` Kees Cook
2022-03-23 15:47     ` Christoph Hellwig
2022-03-23 15:47       ` Christoph Hellwig
2022-03-23 22:33       ` Kees Cook
2022-03-23 22:33         ` Kees Cook
2022-03-24  6:48     ` Christoph Hellwig
2022-03-24  6:48       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yjs/6pLB1uDKBRCG@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=john.garry@huawei.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=martin.petersen@oracle.com \
    --cc=oliver.sang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.