For more details see email log at:
I've had a look at the fs/pipe.c in 2.6.31 :
and it seems that the defect should be present there too.
To reproduce easily, apply the following patch:
--- pipe.c.orig 2009-10-15 20:33:53.000000000 -0700
+++ pipe.c 2009-10-15 20:17:40.000000000 -0700
@@ -736,2 +736,3 @@
then use the attached script to trigger the bug.
Created attachment 23425 [details]
Script to trigger defect
Created attachment 23426 [details]
I just ocasionally went through the
forum where this problem was discussed.
People there had a concern whether the
proposed fix is the best possible solution.
They thought the proper locking must
make the checks like this unneeded.
This raised my curiosity, and after a
quick look at the code, I am wondering too.
If the open() happens on an already released
pipe, then can this be a missing synchronization
in VFS? Of course pipe.c can handle it on
its own, but how does VFS allow such a race?
"fs: pipe.c null pointer dereference"