On Thu, Apr 02, 2026 at 11:52:43AM +0200, Dorinda Bassey wrote:
> Hi Matias,
>
> I've been testing PATCH v13 of the virtio CAN driver and encountered a
> FORTIFY_SOURCE panic when transmitting frames:
>
> sh-5.3# cansend can0 123#DEADBEEF
>
> [ 51.700501] Kernel BUG at __fortify_panic+0x9/0xb [verbose debug
> info unavailable]
> [ 51.700798] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>
> [ 51.700881] CPU: 2 UID: 0 PID: 374 Comm: cansend Tainted: G W
> 6.12.76 #1
> [ 51.701070] Tainted: [W]=WARN
>
> [ 51.701143] RIP: 0010:__fortify_panic+0x9/0xb
>
> [ 51.701212] Code: 01 00 00 e9 58 7e c2 ff cc cc cc cc cc cc cc cc cc
> 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
> 90 40 0f b6 ff e8 57 a9 c2 ff <0f> 0b 48 8b 54 24 08 48 8b 74 24 10 4c
> 8d 44 24 1d 4c 89 e1 48 c7
> [ 51.701406] RSP: 0018:ffffc900001ffb10 EFLAGS: 00010246
>
> [ 51.701454] RAX: 0000000000000000 RBX: ffff888100ea8780 RCX:
> 0000000000000003
> [ 51.701530] RDX: 0000000000000000 RSI: ffffc900001ff9b8 RDI:
> 0000000000000001
> [ 51.701625] RBP: 0000000000000000 R08: 0000000000000000 R09:
> 00000000fffffbff
> [ 51.701700] R10: ffffffff82239ee0 R11: ffffc900001ff9b0 R12:
> ffff888100ea8000
> [ 51.701789] R13: ffff888100817200 R14: ffff88810037cda0 R15:
> ffffc900001ffb48
> [ 51.701866] FS: 00007f7c4cda3740(0000) GS:ffff88812bd00000(0000)
> knlGS:0000000000000000
> [ 51.701948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>
> [ 51.702007] CR2: 00007f7c4ceffdc0 CR3: 0000000100d12000 CR4:
> 0000000000350eb0
> [ 51.702072] Call Trace:
>
> [ 51.702105] <TASK>
>
> [ 51.702126] ? virtio_can_start_xmit.cold+0x2b/0x4d
>
> [ 51.702171] ? srso_alias_return_thunk+0x5/0xfbef5
>
> The issue is in virtio_can_start_xmit() where can_tx_msg->tx_out.length
> is set AFTER memcpy(can_tx_msg->tx_out.sdu, ...). Since sdu[] uses
> __counted_by_le(length), FORTIFY_SOURCE sees length=0 during the copy
> and panics.
>
> The fix is to set length before the memcpy:
>
Thanks I just pick it for v14! I did not observe this behavior before. I
guess they added a new validation that I was not aware of.
Matias
> diff --git a/drivers/net/can/virtio_can.c b/drivers/net/can/virtio_can.c
> index xxx..yyy 100644
> --- a/drivers/net/can/virtio_can.c
> +++ b/drivers/net/can/virtio_can.c
> @@ -308,6 +308,7 @@ static netdev_tx_t virtio_can_start_xmit(struct sk_buff
> *skb,
>
> can_tx_msg->tx_out.msg_type = cpu_to_le16(VIRTIO_CAN_TX);
> + can_tx_msg->tx_out.length = cpu_to_le16(cf->len);
> can_flags = 0;
>
> if (cf->can_id & CAN_EFF_FLAG) {
> @@ -322,7 +323,6 @@ static netdev_tx_t virtio_can_start_xmit(struct sk_buff
> *skb,
> can_flags |= VIRTIO_CAN_FLAGS_FD;
>
> can_tx_msg->tx_out.flags = cpu_to_le32(can_flags);
> - can_tx_msg->tx_out.length = cpu_to_le16(cf->len);
>
> sg_init_one(&sg_out, &can_tx_msg->tx_out, hdr_size + cf->len);
>
> Tested with vhost-device-can backend, and it works correctly after this fix.
>
> Thanks,
> Dorinda Bassey
>
