Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
---
drivers/net/bareudp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-08-06 23:22:38
On Fri, 6 Aug 2021 17:52:06 +0200 Guillaume Nault wrote:
quoted hunk
Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
---
drivers/net/bareudp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
On Fri, Aug 06, 2021 at 04:22:34PM -0700, Jakub Kicinski wrote:
On Fri, 6 Aug 2021 17:52:06 +0200 Guillaume Nault wrote:
quoted
Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
---
drivers/net/bareudp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
No preference just curious - could skb_header_pointer() be better suited?
I have no preference either. I just used skb_copy_bits() because it
didn't seem useful to get a pointer to the buffer (just to read one
byte of data).
But I don't mind reposting with skb_header_pointer() if anyone prefers
that solution.
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-08-09 16:20:54
On Sun, 8 Aug 2021 18:16:25 +0200 Guillaume Nault wrote:
On Fri, Aug 06, 2021 at 04:22:34PM -0700, Jakub Kicinski wrote:
quoted
On Fri, 6 Aug 2021 17:52:06 +0200 Guillaume Nault wrote:
quoted
Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
---
drivers/net/bareudp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 6 Aug 2021 17:52:06 +0200 you wrote:
Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
[...]
On Mon, Aug 09, 2021 at 09:19:18AM -0700, Jakub Kicinski wrote:
On Sun, 8 Aug 2021 18:16:25 +0200 Guillaume Nault wrote:
quoted
On Fri, Aug 06, 2021 at 04:22:34PM -0700, Jakub Kicinski wrote:
quoted
On Fri, 6 Aug 2021 17:52:06 +0200 Guillaume Nault wrote:
quoted
Data beyond the UDP header might not be part of the skb's linear data.
Use skb_copy_bits() instead of direct access to skb->data+X, so that
we read the correct bytes even on a fragmented skb.
Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <redacted>
---
drivers/net/bareudp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
No preference just curious - could skb_header_pointer() be better suited?
I have no preference either. I just used skb_copy_bits() because it
didn't seem useful to get a pointer to the buffer (just to read one
byte of data).
Right, the advantage would be in the "fast" case of skb_header_pointer()
being inlined.
Yes indeed. The problem was found because of some automated functionnal
tests, not because of any practical use cases. So I didn't consider the
possible performance differences.
I see that you've applied the patch as is already. I can switch to
skb_header_pointer() in the future, if anyone sees any practical
benefit for it.
Thanks for the review.