Linux Hardening
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Jussi Kivilinna <jussi.kivilinna@iki.fi>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH][next] ALSA: 6fire: Fix undefined behavior bug in struct comm_runtime
Date: Fri, 06 Oct 2023 10:59:54 +0200	[thread overview]
Message-ID: <87pm1sw2gl.wl-tiwai@suse.de> (raw)
In-Reply-To: <ZRb0WiViajjqcyKT@work>

On Fri, 29 Sep 2023 17:59:22 +0200,
Gustavo A. R. Silva wrote:
> 
> `struct urb` is a flexible structure, which means that it contains a
> flexible-array member at the bottom. This could potentially lead to an
> overwrite of the objects following `receiver` in `struct comm_runtime`,
> among them some function pointers.
> 
> Fix this by placing the declaration of object `receiver` at the end of
> `struct comm_runtime`.
> 
> Fixes: ddb6b5a96437 ("ALSA: 6fire: fix DMA issues with URB transfer_buffer usage")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Sorry for the late reply, as I've been (still) off since the last
week.

Through a quick glance, I don't mind much to apply this, but I still
wonder how this "fixes" anything.  Does it silence compiler warnings
or such?

Certainly struct urb *may* have flex array, but in this case, it's
clearly not used, so it's fixed-size.  And, even if we shuffle the
member to put to the last, it doesn't fix anything automagically
alone.  If a flex array were used, it still leads to memory corruption
unless we implement the allocation properly.  So I find the patch
description is somehow misleading.


thanks,

Takashi

> ---
>  sound/usb/6fire/comm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/6fire/comm.h b/sound/usb/6fire/comm.h
> index 2447d7ecf179..ee81572a4eec 100644
> --- a/sound/usb/6fire/comm.h
> +++ b/sound/usb/6fire/comm.h
> @@ -19,7 +19,6 @@ enum /* settings for comm */
>  struct comm_runtime {
>  	struct sfire_chip *chip;
>  
> -	struct urb receiver;
>  	u8 *receiver_buffer;
>  
>  	u8 serial; /* urb serial */
> @@ -30,6 +29,7 @@ struct comm_runtime {
>  	int (*write8)(struct comm_runtime *rt, u8 request, u8 reg, u8 value);
>  	int (*write16)(struct comm_runtime *rt, u8 request, u8 reg,
>  			u8 vh, u8 vl);
> +	struct urb receiver;
>  };
>  
>  int usb6fire_comm_init(struct sfire_chip *chip);
> -- 
> 2.34.1
> 

      parent reply	other threads:[~2023-10-06  8:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 15:59 [PATCH][next] ALSA: 6fire: Fix undefined behavior bug in struct comm_runtime Gustavo A. R. Silva
2023-09-29 17:26 ` Kees Cook
2023-10-01  6:51   ` Gustavo A. R. Silva
2023-10-06  8:59 ` Takashi Iwai [this message]

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=87pm1sw2gl.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=gustavoars@kernel.org \
    --cc=jussi.kivilinna@iki.fi \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox