aboutsummaryrefslogtreecommitdiff
path: root/fs/ubifs/Makefile
diff options
context:
space:
mode:
authorArtem Bityutskiy <artem.bityutskiy@linux.intel.com>2013-06-28 14:15:14 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-07-03 10:59:05 -0700
commiteafde0bc4fbb118408050b7f32dde3575930ef16 (patch)
tree1cbd0ca69bafdcab08585fd23def28e035bcc381 /fs/ubifs/Makefile
parentf57f135abe8d94c8d83763de99b01d223b60e1df (diff)
UBIFS: prepare to fix a horrid bug
commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream. Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are in the middle of 'ubifs_readdir()'. First of all, this means that 'file->private_data' can be freed while 'ubifs_readdir()' uses it. But this particular patch does not fix the problem. This patch is only a preparation, and the fix will follow next. In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly, because 'file->f_pos' can be changed by '->llseek()' at any point. This may lead 'ubifs_readdir()' to returning inconsistent data: directory entry names may correspond to incorrect file positions. So here we introduce a local variable 'pos', read 'file->f_pose' once at very the beginning, and then stick to 'pos'. The result of this is that when 'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of 'ubifs_readdir()', the latter "wins". Reported-by: Al Viro <viro@zeniv.linux.org.uk> Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'fs/ubifs/Makefile')
0 files changed, 0 insertions, 0 deletions