Linux-USB Archive on
 help / color / Atom feed
From: Alan Stern <>
To: Andrey Konovalov <>
Cc: Jaskaran Singh <>,
	syzbot <>,
	Alexander Potapenko <>,
	Greg Kroah-Hartman <>,
	LKML <>,
	USB list <>,
	syzkaller-bugs <>,
Subject: Re: KMSAN: uninit-value in alauda_check_media
Date: Fri, 11 Oct 2019 10:53:47 -0400 (EDT)
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 11 Oct 2019, Andrey Konovalov wrote:

> On Fri, Oct 11, 2019 at 4:08 PM Alan Stern <> wrote:

> > Now yes, it's true that defining status as an array on the stack is
> > also a bug, since USB transfer buffers are not allowed to be stack
> > variables.
> Hi Alan,
> I'm curious, what is the reason for disallowing that? Should we try to
> somehow detect such cases automatically?

Transfer buffers are read and written by DMA.  On systems that don't
have cache-coherent DMA controllers, it is essential that the CPU does
not access any cache line involved in a DMA transfer while the transfer
is in progress.  Otherwise the data in the cache would be different
from the data in the buffer, leading to corruption.

(In theory it would be okay for the CPU to read (not write!) a cache
line assigned to a buffer for a DMA write (not read!) transfer.  But
even doing that isn't really a good idea.)

(Also, this isn't an issue for x86 architectures, because x86 has 
cache-coherent DMA.  But it is an issue on other architectures.)

In practice, this means transfer buffers have to be allocated by
something like kmalloc, so that they occupies their own separate set of
cache lines.  Buffers on the stack obviously don't satisfy this

At some point there was a discussion about automatically detecting when
on-stack (or otherwise invalid) buffers are used for DMA transfers.  I
don't recall what the outcome was.

Alan Stern

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 19:39 syzbot
2019-10-11 11:23 ` Jaskaran Singh
2019-10-11 11:51   ` Alexander Potapenko
2019-10-11 15:42     ` syzbot
2019-10-11 14:08   ` Alan Stern
2019-10-11 14:18     ` Andrey Konovalov
2019-10-11 14:53       ` Alan Stern [this message]
2019-10-11 15:06         ` Greg Kroah-Hartman
2019-10-14 12:56           ` Andrey Konovalov
2019-10-11 15:24   ` syzbot
2019-10-11 11:17 Jas K

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-USB Archive on

Archives are clonable:
	git clone --mirror linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ \
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone