On (01/27/17 14:29), Willem de Bruijn wrote: > > As your patch state, the contract is that any packet delivered to a > driver has the entire L2 in its linear section. Drivers are not required > to be robust against shorter packets, so there is no reason to test > those. > > One option is to limit your fix to known fixed-header protocols. > In these cases hard_header_len is the minimum, so anything > smaller must be dropped.
yes, but how would you you know that this is a fixed-header protocol or a var-hdrlen protocol? AIUI the hard_header_len itself will not tell you this info: it will be 77 for ax25, 14 for ethernet, but that does not tell me that ax25 is the "robust-er" driver with a min requirement of 21 for the hdrlen. That's why I was thinking of a IFF_L2_VARHDRLEN in the priv_flags of the net_device. > For protocols with variable header length it is fine to send packets > shorter than hard_header_len, even with corrupted content (i.e., > even if they would fail that protocol's validate callback), as long as > they exceed the minimum length. ax25 already has a min length > check through its protocol-specific validate callback. Another option that comes to mind.. the real thorn-in-the-flesh here is the CAP_SYS_RAWIO check. Would it be a better idea to ask the test-suites (since they seem to be the major consumer of that path) to use a special PF_PACKET socket option instead, that indicates "I'm testing robustness of the header, so let this one slip past dev_validate_header at all times"? It would mean the test suites would have to change slightly. --Sowmini
