Hello!
I am looking at fs/isofs/rock.c::MAYBE_CONTINUE() macros
in latest 2.4 bk tree. (latest 2.5 have the same problem)
Seems that it opens a memleak in case of read error of rock-ridge attribute.
The caller of the macros assumes that when MAYBE_CONTINUE macros is over
(and not jumping to "out" label), then buffer is freed. (The funny thing is
that the macro only jumps to "out" if buffer allocation failed now, so
nothing to free, and every caller tries to free buffer if possible).
Perhaps something like following patch should help (applies to 2.4 and 2.5).
Found with help of smatch and enchanced unfree script.
Bye,
Oleg
===== fs/isofs/rock.c 1.6 vs edited =====
--- 1.6/fs/isofs/rock.c Tue Feb 5 17:10:25 2002
+++ edited/fs/isofs/rock.c Sun Mar 9 21:23:07 2003
@@ -81,6 +81,7 @@
goto LABEL; \
} \
printk("Unable to read rock-ridge attributes\n"); \
+ goto out;
}}
/* This is the inner layer of the get filename routine, and is called
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:18 EST