Skip to contentSkip to conversation

tc: Fix unitialized kernel memory leak

PATCH In review Eric Dumazet 4 participants 7 messages Sep 2, 2009 – Sep 3, 2009

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 tc: Fix unitialized kernel memory leak

Three bytes of uninitialized kernel memory are currently leaked to user

---

net/sched/sch_api.c +2 -0
index 24d17ce..fdb694e 100644
@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
 	nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
 	tcm = NLMSG_DATA(nlh);
 	tcm->tcm_family = AF_UNSPEC;
+	tcm->tcm__pad1 = 0;
+	tcm->tcm__pad2 = 0;
 	tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
 	tcm->tcm_parent = q->handle;
 	tcm->tcm_handle = q->handle;
Reviewed-by on v1 1/1
#1 lore raw
Quoted 3 lines · Wed, Sep 02, 2009 at 02:40:09PM CEST, [email protected] wrote:

Three bytes of uninitialized kernel memory are currently leaked to user

Quoted 18 lines

---

net/sched/sch_api.c +2 -1
index 24d17ce..fdb694e 100644
@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
 	nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
 	tcm = NLMSG_DATA(nlh);
 	tcm->tcm_family = AF_UNSPEC;
+	tcm->tcm__pad1 = 0;
+	tcm->tcm__pad2 = 0;
 	tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
 	tcm->tcm_parent = q->handle;
 	tcm->tcm_handle = q->handle;
--

To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
In reply to Eric Dumazet
Quoted 9 lines · On Wed, 02 Sep 2009 14:40:09 +0200 Eric Dumazet <[email protected]> wrote:

Three bytes of uninitialized kernel memory are currently leaked to user

---

net/sched/sch_api.c +0 -0
index 24d17ce..fdb694e 100644

net/sched/sch_api.c static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q, · line 1463

Quoted 8 lines
net/sched/sch_api.c +2 -0
@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
 	nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
 	tcm = NLMSG_DATA(nlh);
 	tcm->tcm_family = AF_UNSPEC;
+	tcm->tcm__pad1 = 0;
+	tcm->tcm__pad2 = 0;
 	tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
 	tcm->tcm_parent = q->handle;
 	tcm->tcm_handle = q->handle;

Perhaps __nlmsg_put should just always call memset() for the whole added chunk. It is not like it is critical path in any way, and avoid any of this possible class of errors.

maintainer
#4 lore raw

From: Stephen Hemminger <[email protected]>
Date: Wed, 2 Sep 2009 12:05:40 -0700

Quoted 16 lines
Quoted 13 lines · On Wed, 02 Sep 2009 14:40:09 +0200 Eric Dumazet <[email protected]> wrote:

Three bytes of uninitialized kernel memory are currently leaked to user

---

net/sched/sch_api.c +1 -0
index 24d17ce..fdb694e 100644
@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
 	nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
 	tcm = NLMSG_DATA(nlh);
 	tcm->tcm_family = AF_UNSPEC;
+	tcm->tcm__pad1 = 0;
Quoted 8 lines

net/sched/sch_api.c static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q, · line 1463

Quoted 4 lines
net/sched/sch_api.c +1 -0
+	tcm->tcm__pad2 = 0;
 	tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
 	tcm->tcm_parent = q->handle;
 	tcm->tcm_handle = q->handle;

Perhaps __nlmsg_put should just always call memset() for the whole added chunk. It is not like it is critical path in any way, and avoid any of this possible class of errors.

Doing it in __nlmsg_put would effect a lot of code paths. I don't think you can say with certainty that it won't matter, tree wide.

What about things like the netfilter conntrack event monitor? Doesn't that emit hundreds of thousands of events per second on a busy firewall?

#5 lore raw
Quoted 28 lines · On Wed, 02 Sep 2009 22:51:08 -0700 (PDT) David Miller <[email protected]>…

From: Stephen Hemminger <[email protected]>
Date: Wed, 2 Sep 2009 12:05:40 -0700

Quoted 16 lines
Quoted 13 lines · On Wed, 02 Sep 2009 14:40:09 +0200 Eric Dumazet <[email protected]> wrote:

Three bytes of uninitialized kernel memory are currently leaked to user

---

net/sched/sch_api.c +1 -0
index 24d17ce..fdb694e 100644
@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
 	nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
 	tcm = NLMSG_DATA(nlh);
 	tcm->tcm_family = AF_UNSPEC;
+	tcm->tcm__pad1 = 0;
Quoted 8 lines

net/sched/sch_api.c static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q, · line 1463

Quoted 4 lines
net/sched/sch_api.c +1 -0
+	tcm->tcm__pad2 = 0;
 	tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
 	tcm->tcm_parent = q->handle;
 	tcm->tcm_handle = q->handle;

Perhaps __nlmsg_put should just always call memset() for the whole added chunk. It is not like it is critical path in any way, and avoid any of this possible class of errors.

Quoted 6 lines

Doing it in __nlmsg_put would effect a lot of code paths. I don't think you can say with certainty that it won't matter, tree wide.

What about things like the netfilter conntrack event monitor? Doesn't that emit hundreds of thousands of events per second on a busy firewall?

I doubt it would make a noticeable performance difference because the first memset would incur the cache penalty of the write (if any) and later update of fields would be cached.

maintainer
#6 lore raw

From: Stephen Hemminger <[email protected]>
Date: Wed, 2 Sep 2009 23:34:10 -0700

Quoted 3 lines

I doubt it would make a noticeable performance difference because the first memset would incur the cache penalty of the write (if any) and later update of fields would be cached.

Indeed, but it also means your store buffer usage is half as effective. And when writing a ton of messages that might be important.