On Sat. 14 May 2022 at 12:29, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 11.05.2022 15:24:21, Marc Kleine-Budde wrote: > > On 11.05.2022 14:38:32, Oliver Hartkopp wrote: > > > IMO this patch does not work as intended. > > > > > > You probably need to revisit every place where can_skb_reserve() is used, > > > e.g. in raw_sendmsg(). > > > > And the loopback for devices that don't support IFF_ECHO: > > > > | https://elixir.bootlin.com/linux/latest/source/net/can/af_can.c#L257 > > BTW: There is a bug with interfaces that don't support IFF_ECHO. > > Assume an invalid CAN frame is passed to can_send() on an interface that > doesn't support IFF_ECHO. The above mentioned code does happily generate > an echo frame and it's send, even if the driver drops it, due to > can_dropped_invalid_skb(dev, skb). > > The echoed back CAN frame is treated in raw_rcv() as if the headroom is valid: > > | https://elixir.bootlin.com/linux/v5.17.6/source/net/can/raw.c#L138 > > But as far as I can see the can_skb_headroom_valid() check never has > been done. What about this patch? > > index 1fb49d51b25d..fda4807ad165 100644 > --- a/net/can/af_can.c > +++ b/net/can/af_can.c > @@ -255,6 +255,9 @@ int can_send(struct sk_buff *skb, int loop) > */ > > if (!(skb->dev->flags & IFF_ECHO)) { > + if (can_dropped_invalid_skb(dev, skb)) > + return -EINVAL; > + This means that can_dropped_invalid_skb() would be called twice: one time in can_send() and one time in the driver's xmit() function, right? It would be nice to find a trick to detect whether the skb was injected through the packet socket or not in order not to execute can_dropped_invalid_skb() twice. I guess the information of the provenance of the skb is available somewhere, just not sure where (not familiar with the packet socket). Yours sincerely, Vincent Mailhol
