diff mbox series

[v2] net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue

Message ID 20200103045016.12459-1-wgong@codeaurora.org (mailing list archive)
State New, archived
Headers show
Series [v2] net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue | expand

Commit Message

Wen Gong Jan. 3, 2020, 4:50 a.m. UTC 
From: Carl Huang <cjhuang@codeaurora.org>

The len used for skb_put_padto is wrong, it need to add len of hdr.

In qrtr_node_enqueue, local variable size_t len is assign with
skb->len, then skb_push(skb, sizeof(*hdr)) will add skb->len with
sizeof(*hdr), so local variable size_t len is not same with skb->len
after skb_push(skb, sizeof(*hdr)).

Then the purpose of skb_put_padto(skb, ALIGN(len, 4)) is to add add
pad to the end of the skb's data if skb->len is not aligned to 4, but
unfortunately it use len instead of skb->len, at this line, skb->len
is 32 bytes(sizeof(*hdr)) more than len, for example, len is 3 bytes,
then skb->len is 35 bytes(3 + 32), and ALIGN(len, 4) is 4 bytes, so
__skb_put_padto will do nothing after check size(35) < len(4), the
correct value should be 36(sizeof(*hdr) + ALIGN(len, 4) = 32 + 4),
then __skb_put_padto will pass check size(35) < len(36) and add 1 byte
to the end of skb's data, then logic is correct.

function of skb_push:
void *skb_push(struct sk_buff *skb, unsigned int len)
{
	skb->data -= len;
	skb->len  += len;
	if (unlikely(skb->data < skb->head))
		skb_under_panic(skb, len, __builtin_return_address(0));
	return skb->data;
}

function of skb_put_padto
static inline int skb_put_padto(struct sk_buff *skb, unsigned int len)
{
	return __skb_put_padto(skb, len, true);
}

function of __skb_put_padto
static inline int __skb_put_padto(struct sk_buff *skb, unsigned int len,
				  bool free_on_error)
{
	unsigned int size = skb->len;

	if (unlikely(size < len)) {
		len -= size;
		if (__skb_pad(skb, len, free_on_error))
			return -ENOMEM;
		__skb_put(skb, len);
	}
	return 0;
}

Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v2: change description
 net/qrtr/qrtr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

David Miller Jan. 5, 2020, 10:47 p.m. UTC | #1 
From: Wen Gong <wgong@codeaurora.org>
Date: Fri,  3 Jan 2020 12:50:16 +0800

> The len used for skb_put_padto is wrong, it need to add len of hdr.

Thanks, applied.

There is another bug here, skb_put_padto() returns an error and frees
the SKB when the put fails.  There really needs to be a check here,
because currently the code right now will keep using the freed up
skb in that situation.

Thanks.
Wen Gong Jan. 6, 2020, 2:04 a.m. UTC | #2 
On 2020-01-06 06:47, David Miller wrote:
> From: Wen Gong <wgong@codeaurora.org>
> Date: Fri,  3 Jan 2020 12:50:16 +0800
> 
>> The len used for skb_put_padto is wrong, it need to add len of hdr.
> 
> Thanks, applied.
> 
> There is another bug here, skb_put_padto() returns an error and frees
> the SKB when the put fails.  There really needs to be a check here,
> because currently the code right now will keep using the freed up
> skb in that situation.
> 

Thanks David.

Yes, __skb_put_padto will return -ENOMEM if __skb_pad fail.
I think it can return the same error immediately and do not do the next 
steps in qrtr_node_enqueue.
> Thanks.
Doug Anderson Feb. 25, 2020, 10:52 p.m. UTC | #3 
Hi,


On Sun, Jan 5, 2020 at 2:47 PM David Miller <davem@davemloft.net> wrote:
>
> From: Wen Gong <wgong@codeaurora.org>
> Date: Fri,  3 Jan 2020 12:50:16 +0800
>
> > The len used for skb_put_padto is wrong, it need to add len of hdr.
>
> Thanks, applied.

I noticed this patch is in mainline now as:

ce57785bf91b net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue

Though I'm not an expert on the code, it feels like a stable candidate
unless someone objects.

-Doug
David Miller Feb. 27, 2020, 4:28 a.m. UTC | #4 
From: Doug Anderson <dianders@chromium.org>
Date: Tue, 25 Feb 2020 14:52:24 -0800

> I noticed this patch is in mainline now as:
> 
> ce57785bf91b net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
> 
> Though I'm not an expert on the code, it feels like a stable candidate
> unless someone objects.

Ok, queued up, thanks.
Greg KH March 17, 2020, 10:26 a.m. UTC | #5 
On Tue, Feb 25, 2020 at 02:52:24PM -0800, Doug Anderson wrote:
> Hi,
> 
> 
> On Sun, Jan 5, 2020 at 2:47 PM David Miller <davem@davemloft.net> wrote:
> >
> > From: Wen Gong <wgong@codeaurora.org>
> > Date: Fri,  3 Jan 2020 12:50:16 +0800
> >
> > > The len used for skb_put_padto is wrong, it need to add len of hdr.
> >
> > Thanks, applied.
> 
> I noticed this patch is in mainline now as:
> 
> ce57785bf91b net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
> 
> Though I'm not an expert on the code, it feels like a stable candidate
> unless someone objects.

Stable candidate for what tree(s)?

thanks,

greg k-h
Doug Anderson March 17, 2020, 3:45 p.m. UTC | #6 
Hi,

On Tue, Mar 17, 2020 at 3:26 AM Greg KH <greg@kroah.com> wrote:
>
> On Tue, Feb 25, 2020 at 02:52:24PM -0800, Doug Anderson wrote:
> > Hi,
> >
> >
> > On Sun, Jan 5, 2020 at 2:47 PM David Miller <davem@davemloft.net> wrote:
> > >
> > > From: Wen Gong <wgong@codeaurora.org>
> > > Date: Fri,  3 Jan 2020 12:50:16 +0800
> > >
> > > > The len used for skb_put_padto is wrong, it need to add len of hdr.
> > >
> > > Thanks, applied.
> >
> > I noticed this patch is in mainline now as:
> >
> > ce57785bf91b net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
> >
> > Though I'm not an expert on the code, it feels like a stable candidate
> > unless someone objects.
>
> Stable candidate for what tree(s)?

I noticed that it was lacking and applied cleanly on 5.4.  As of
5.4.25 it's still not stable there.  I only noticed it because I was
comparing all the patches in mainline in "net/qrtr" with what we had
in our tree and stumbled upon this one.

Looking at it a little more carefully, I guess you could say:

Fixes: e7044482c8ac ("net: qrtr: Pass source and destination to
enqueue functions")

...though it will be trickier to apply past commit 194ccc88297a ("net:
qrtr: Support decoding incoming v2 packets") just because the math
changed.

-Doug
Greg KH March 19, 2020, 7:46 a.m. UTC | #7 
On Tue, Mar 17, 2020 at 08:45:09AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Mar 17, 2020 at 3:26 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Feb 25, 2020 at 02:52:24PM -0800, Doug Anderson wrote:
> > > Hi,
> > >
> > >
> > > On Sun, Jan 5, 2020 at 2:47 PM David Miller <davem@davemloft.net> wrote:
> > > >
> > > > From: Wen Gong <wgong@codeaurora.org>
> > > > Date: Fri,  3 Jan 2020 12:50:16 +0800
> > > >
> > > > > The len used for skb_put_padto is wrong, it need to add len of hdr.
> > > >
> > > > Thanks, applied.
> > >
> > > I noticed this patch is in mainline now as:
> > >
> > > ce57785bf91b net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
> > >
> > > Though I'm not an expert on the code, it feels like a stable candidate
> > > unless someone objects.
> >
> > Stable candidate for what tree(s)?
> 
> I noticed that it was lacking and applied cleanly on 5.4.  As of
> 5.4.25 it's still not stable there.  I only noticed it because I was
> comparing all the patches in mainline in "net/qrtr" with what we had
> in our tree and stumbled upon this one.
> 
> Looking at it a little more carefully, I guess you could say:
> 
> Fixes: e7044482c8ac ("net: qrtr: Pass source and destination to
> enqueue functions")
> 
> ...though it will be trickier to apply past commit 194ccc88297a ("net:
> qrtr: Support decoding incoming v2 packets") just because the math
> changed.

Given that both of those commits showed up in 4.15, it doesn't matter
much :)

I've queued this up for 5.4.y and 4.19.y now, thanks.

greg k-h
diff mbox series

Patch

diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 88f98f27ad88..3d24d45be5f4 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -196,7 +196,7 @@  static int qrtr_node_enqueue(struct qrtr_node *node, struct sk_buff *skb,
 	hdr->size = cpu_to_le32(len);
 	hdr->confirm_rx = 0;
 
-	skb_put_padto(skb, ALIGN(len, 4));
+	skb_put_padto(skb, ALIGN(len, 4) + sizeof(*hdr));
 
 	mutex_lock(&node->ep_lock);
 	if (node->ep)