HellO!
> I like this. However, since the cloned skb is either discarded in case
> of error, or queued in which case the caller discards its reference right
> away, wouldn't it be simpler to just do this?
Well, if we wanted just to cheat those checking tools, it is nice.
But if we want clarity, i
Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
>
> I think you mean this.
>
> Note, it is real skb_clone(), not alloc_skb(). Equeued skb contains
> the whole half-prepared netlink message plus room for the rest.
> It could be also skb_copy(), if we want to be puristic about mangling
> cloned data, b
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2006 01:17:25 +0400
> Hello!
>
> > Wouldn't it be better to have a consistent interface (skb always freed),
> > and clone the skb if needed for deferred processing?
>
> I think you mean this.
>
> Note, it is real skb_clone(), not allo
On Wed, 26 Jul 2006 01:17:25 +0400
Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Wouldn't it be better to have a consistent interface (skb always freed),
> > and clone the skb if needed for deferred processing?
>
> I think you mean this.
>
> Note, it is real skb_clone(), not alloc_
Hello!
> Wouldn't it be better to have a consistent interface (skb always freed),
> and clone the skb if needed for deferred processing?
I think you mean this.
Note, it is real skb_clone(), not alloc_skb(). Equeued skb contains
the whole half-prepared netlink message plus room for the rest.
It c
Hello!
> Wouldn't it be better to have a consistent interface (skb always freed),
> and clone the skb if needed for deferred processing?
I am sorry, I misunderstood you. I absolutely agree. It is much better,
the variant which I suggested is a good sample of bad programming. :-)
Alexey
-
To uns
Hello!
> checking tools because the skb lifetime depends on the return value.
> Wouldn't it be better to have a consistent interface (skb always freed),
> and clone the skb if needed for deferred processing?
But skb is not always freed in any case.
Normally it is submitted to netlink_unicast(). I
On Tue, 25 Jul 2006 20:20:01 +0400
Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Code was reusing an skb which could lead to use after free or double free.
>
> No, this does not help. The bug is not here.
>
> I was so ashamed of this that could not touch the thing. :-)
> It startle
IP multicast route code was reusing an skb which causes
use after free and double free.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/ipmr.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index b
Hello!
> Code was reusing an skb which could lead to use after free or double free.
No, this does not help. The bug is not here.
I was so ashamed of this that could not touch the thing. :-)
It startled me a lot, how is it possible that the thing was in production
for several years and such bad b
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> @@ -1593,12 +1594,19 @@ int ipmr_get_route(struct sk_buff *skb,
>read_unlock(&mrt_lock);
>return -ENODEV;
>}
> - skb->nh.raw = skb_push(skb, sizeof(struct iphdr));
> -
On Wed, 2006-07-19 at 14:57 -0700, Stephen Hemminger wrote:
> This should fix the problem reported in
> http://bugzilla.kernel.org/show_bug.cgi?id=6186
> where the skb is used after freed. The code in IP multicast route.
>
> Code was reusing an skb which could lead to use after free or double fre
On Wed, 19 Jul 2006, Stephen Hemminger wrote:
> This should fix the problem reported in
> http://bugzilla.kernel.org/show_bug.cgi?id=6186
> where the skb is used after freed. The code in IP multicast route.
>
> Code was reusing an skb which could lead to use after free or double free.
>
> Signe
This should fix the problem reported in
http://bugzilla.kernel.org/show_bug.cgi?id=6186
where the skb is used after freed. The code in IP multicast route.
Code was reusing an skb which could lead to use after free or double free.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4
14 matches
Mail list logo
