| To: | Tobias DiPasquale <toby@xxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] kfree_skb() bug in 2.4.22 |
| From: | Jeff Garzik <jgarzik@xxxxxxxxx> |
| Date: | Wed, 08 Oct 2003 09:09:48 -0400 |
| Cc: | netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, coreteam@xxxxxxxxxxxxx, netfilter@xxxxxxxxxxxxxxxxxxx, akpm@xxxxxxxxxx, davem@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, pekkas@xxxxxxxxxx, jmorris@xxxxxxxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx |
| In-reply-to: | <1065617075.1514.29.camel@localhost> |
| References: | <1065617075.1514.29.camel@localhost> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 |
Tobias DiPasquale wrote: Hi all, I was debugging one of my iptables/netfilter modules yesterday and I came across this bug in kfree_skb(). One of my functions returns a struct skbuff * on success and NULL on failure. When it failed, the code calling said function attempted to free the struct skbuff *, which at that point was NULL. This produced a kernel panic. I investigated the problem and found that, not only should I be checking for a NULL pointer when freeing the struct skbuff *, but the actual cause of the panic was because kfree_skb() and kfree_skb_fast() do not check for skb==NULL, either. They immediately attempt to dereference the users field of thestruct skbuff * in order to decrement that reference counter. I would prefer that you fix your code instead, to not pass NULL to kfree_skb()... |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] Handle shared SKBs in VLAN receive code, Tommy Christensen |
|---|---|
| Next by Date: | [PATCH 2.6] ethtool_ops eeprom stuff, Feldman, Scott |
| Previous by Thread: | [PATCH] kfree_skb() bug in 2.4.22, Tobias DiPasquale |
| Next by Thread: | Re: [PATCH] kfree_skb() bug in 2.4.22, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |