| Message ID | ZRb0WiViajjqcyKT@work |
|---|---|
| State | New |
| Headers | show |
| Series | [next] ALSA: 6fire: Fix undefined behavior bug in struct comm_runtime | expand |
On 9/29/23 19:26, Kees Cook wrote: > On Fri, Sep 29, 2023 at 05:59:22PM +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> > > Should these mention -Wflex-array-member-not-at-end ? Probably, yes. I wasn't sure about mentioning it because it's not been released yet. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Thanks! -- Gustavo
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 >
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);
`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> --- sound/usb/6fire/comm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)