Skip to contentSkip to conversation

kprobes: initialize before using a hlist

PATCH RESEND In review Ananth N Mavinakayanahalli 3 participants 3 messages Jan 9, 2012 – Jan 10, 2012

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

PATCH RESEND 1/1 kprobes: initialize before using a hlist

From: Ananth N Mavinakayanahalli <[email protected]>

Commit ef53d9c5e introduced a bug where we can potentially leak kretprobe_instances since we initialize a hlist head after having used it.

Initialize the hlist head before using it.

(Resent with correct email ID for -stable)

Reported by: Jim Keniston <[email protected]>

---
 kernel/kprobes.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/kprobes.c +1 -1
Index: linux-3.2/kernel/kprobes.c
===================================================================
@@ -1077,6 +1077,7 @@ void __kprobes kprobe_flush_task(struct 
 		/* Early boot.  kretprobe_table_locks not yet initialized. */
 		return;
 
+	INIT_HLIST_HEAD(&empty_rp);
 	hash = hash_ptr(tk, KPROBE_HASH_BITS);
 	head = &kretprobe_inst_table[hash];
 	kretprobe_table_lock(hash, &flags);
@@ -1085,7 +1086,6 @@ void __kprobes kprobe_flush_task(struct 
 			recycle_rp_inst(ri, &empty_rp);
 	}
 	kretprobe_table_unlock(hash, &flags);
-	INIT_HLIST_HEAD(&empty_rp);
 	hlist_for_each_entry_safe(ri, node, tmp, &empty_rp, hlist) {
 		hlist_del(&ri->hlist);
 		kfree(ri);
Acked-by on v1 1/1
#1 lore raw
Quoted 6 lines · Ananth N Mavinakayanahalli

From: Ananth N Mavinakayanahalli <[email protected]>

Commit ef53d9c5e introduced a bug where we can potentially leak kretprobe_instances since we initialize a hlist head after having used it.

Quoted 8 lines

Initialize the hlist head before using it.

(Resent with correct email ID for -stable)

Reported by: Jim Keniston <[email protected]>

Quoted 24 lines
---
 kernel/kprobes.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-3.2/kernel/kprobes.c
===================================================================

kernel/kprobes.c +1 -1
@@ -1077,6 +1077,7 @@ void __kprobes kprobe_flush_task(struct 
 		/* Early boot.  kretprobe_table_locks not yet initialized. */
 		return;
 
+	INIT_HLIST_HEAD(&empty_rp);
 	hash = hash_ptr(tk, KPROBE_HASH_BITS);
 	head = &kretprobe_inst_table[hash];
 	kretprobe_table_lock(hash, &flags);
@@ -1085,7 +1086,6 @@ void __kprobes kprobe_flush_task(struct 
 			recycle_rp_inst(ri, &empty_rp);
 	}
 	kretprobe_table_unlock(hash, &flags);
-	INIT_HLIST_HEAD(&empty_rp);
 	hlist_for_each_entry_safe(ri, node, tmp, &empty_rp, hlist) {
 		hlist_del(&ri->hlist);
 		kfree(ri);
#2 lore raw
Quoted 9 lines · Jim Keniston
Quoted 8 lines · Ananth N Mavinakayanahalli

From: Ananth N Mavinakayanahalli <[email protected]>

Commit ef53d9c5e introduced a bug where we can potentially leak kretprobe_instances since we initialize a hlist head after having used it.

Initialize the hlist head before using it.

Quoted 8 lines
Quoted 6 lines

(Resent with correct email ID for -stable)

Reported by: Jim Keniston <[email protected]>

Thank you!

Quoted 32 lines
Quoted 18 lines
---
 kernel/kprobes.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-3.2/kernel/kprobes.c
===================================================================

kernel/kprobes.c +1 -0
@@ -1077,6 +1077,7 @@ void __kprobes kprobe_flush_task(struct 
 		/* Early boot.  kretprobe_table_locks not yet initialized. */
 		return;
 
+	INIT_HLIST_HEAD(&empty_rp);
 	hash = hash_ptr(tk, KPROBE_HASH_BITS);
 	head = &kretprobe_inst_table[hash];
 	kretprobe_table_lock(hash, &flags);

kernel/kprobes.c void __kprobes kprobe_flush_task(struct · line 1091

Quoted 7 lines
kernel/kprobes.c +0 -1
@@ -1085,7 +1086,6 @@ void __kprobes kprobe_flush_task(struct 
 			recycle_rp_inst(ri, &empty_rp);
 	}
 	kretprobe_table_unlock(hash, &flags);
-	INIT_HLIST_HEAD(&empty_rp);
 	hlist_for_each_entry_safe(ri, node, tmp, &empty_rp, hlist) {
 		hlist_del(&ri->hlist);
 		kfree(ri);

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

Signature · 4 lines
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: [email protected]