Re: [PATCH] can: usb: f81604: fix struct f81604_int_data size mismatch

[Dynetrex, Admin]

Hey Greg, 

This issue was reported by me about a month and a half ago, however, I did not have an environment setup for kernel development in order to submit a patch.

I appreciate Peter taking a look at this.

Kind Regards,
Alex

> On Aug 24, 2026, at 2:08 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Mon, Aug 24, 2026 at 04:27:58PM +0800, PS10 PETER HONG 洪繼澤 wrote:
>> The struct f81604_int_data defines 9 bytes of interrupt data:
>> - Byte 0: Status register (sr)
>> - Byte 1: Interrupt register (isrc)
>> - Byte 2: Interrupt enable register (ier)
>> - Byte 3: Arbitration lost capture (alc)
>> - Byte 4: Error code capture (ecc)
>> - Byte 5: Error warning limit register (ewlr)
>> - Byte 6: RX error counter (rxerr)
>> - Byte 7: TX error counter (txerr)
>> - Byte 8: Reserved (val)
>> 
>> The hardware sends exactly 9 bytes for the interrupt endpoint.
>> However, the struct was defined with __aligned(4) attribute which
>> caused the compiler to pad the struct to 12 bytes.
>> 
>> This causes a problem in f81604_read_int_callback() where the short
>> URB check compares urb->actual_length against sizeof(*data). When
>> sizeof(struct f81604_int_data) is 12 but the hardware only sends 9
>> bytes, the check fails and valid interrupt messages are discarded.
>> 
>> This results in the driver only being able to transmit once because
>> the TX complete interrupt is never processed.
>> 
>> Fix this by removing the __aligned(4) attribute so the struct size
>> matches the actual hardware data size of 9 bytes.
>> 
>> Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support")
>> Fixes: 7299b1b39a25 ("can: usb: f81604: handle short interrupt urb messages properly")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Ji-Ze Hong (Peter Hong) <peter_hong@xxxxxxxxxxxxx>
> 
> Nit, doesn't match the From: line :(
> 
> Also, the first Fixes: tag isn't correct, it's the second one that
> matters.
> 
> And wasn't this reported by someone already:
> 	https://lore.kernel.org/r/A3834A07-5639-4779-844F-C5843DFC3928@xxxxxxxxxxxx
> ?
> 
> And yes, this patch does look correct.
> 
> thanks,
> 
> greg k-h