The inode double locking code in fs/ocfs2/file.c in the Linux kernel 2.6.30 before 2.6.30-rc3, 2.6.27 before 2.6.27.24, 2.6.29 before 2.6.29.4, and possibly other versions down to 2.6.19 allows local users to cause a denial of service (prevention of file creation and removal) via a series of splice system calls that trigger a deadlock between the generic_file_splice_write, splice_from_pipe, and ocfs2_file_splice_write functions.
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Linux_kernel | Linux | * | 2.6.19 (including) |
| Linux_kernel | Linux | 2.6.27 (including) | 2.6.27.24 (excluding) |
| Linux_kernel | Linux | 2.6.29 (including) | 2.6.29.4 (excluding) |
| Linux_kernel | Linux | 2.6.30-rc1 (including) | 2.6.30-rc1 (including) |
| Linux_kernel | Linux | 2.6.30-rc2 (including) | 2.6.30-rc2 (including) |
| MRG for RHEL-5 | RedHat | kernel-rt-0:2.6.24.7-126.el5rt | * |
| Linux | Ubuntu | hardy | * |
| Linux | Ubuntu | intrepid | * |
| Linux | Ubuntu | jaunty | * |
| Linux | Ubuntu | upstream | * |
| Linux-source-2.6.15 | Ubuntu | dapper | * |
| Linux-source-2.6.15 | Ubuntu | upstream | * |
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.