Sending a LOCK refresh request to an indirectly locked resource crashes the server. Steps to reproduce: MKCOL x PUT x/y LOCK x try to refresh the lock through x/y, so LOCK x/y (Test case will be attached separately).
Created attachment 12710 [details] test case (needs JScript/Windows; but can easily rewritten for other environments)
Is it crashing using all three If headers formats? I couldn't reproduce from a quick test here (on Unix). Can you get a backtrace out of the server?
Yes, all of them, it seems. How do I get the backtrace?
Never mind, I've reproduced it. It's a NULL pointer dereference in fs/lock.c: /* the lock was refreshed. return the lock. */ newlock = dav_fs_alloc_lock(lockdb, ip->key, dp->locktoken); newlock->is_locknull = !resource->exists; dp is NULL at time of invocation.
Thanks for the report, Julian. This is what I committed: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/fs/lock.c?r1=1.32&r2=1.33 if you could re-run your tests with that patch applied that would be great. It passes the litmus test I added.
This is fixed in 2.0.51, thanks again.
(In reply to comment #0) > Sending a LOCK refresh request to an indirectly locked resource crashes the server. > Steps to reproduce: > MKCOL x > PUT x/y > LOCK x > try to refresh the lock through x/y, so > LOCK x/y > (Test case will be attached separately).