Messages in this thread | | | Date | Fri, 22 Mar 2013 17:31:16 +0800 | Subject | Re: [PATCH 1/2] sysfs: fix race between readdir and lseek | From | Ming Lei <> |
| |
On Fri, Mar 22, 2013 at 1:48 PM, Li Zefan <lizefan@huawei.com> wrote: > On 2013/3/21 12:48, Ming Lei wrote: > > Yes, it can...As I said, it's irrelevant, because it's vfs that changes > file->f_pos. > > SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count) > { > struct fd f = fdget(fd); > ssize_t ret = -EBADF; > > if (f.file) { > loff_t pos = file_pos_read(f.file); <--- read f_pos > ret = vfs_read(f.file, buf, count, &pos); <--- return -EISDIR > file_pos_write(f.file, pos); <--- write f_pos
Considered that f_pos of sysfs directory is always less than INT_MAX, we need't worry about atomic writing it in file_pos_write().
The only probable problem on sysfs is below scenario in read()/write():
- pos is read as less than 2 in file_pos_read(f.file) - ret = vfs_read(f.file, buf, count, &pos) ---> readdir() in another path - file_pos_write(pos) ---> readdir() found f_pos becomes 0 or 1, and may cause use-after-free problem
Considered that vfs_read()/vfs_write on sysfs dir is almost doing nothing, the above problem may only exist in theory. The patch[1] can't avoid it too. I am wondering if it need to be fixed, but I will try to figure out how to avoid it in sysfs_readdir() if possible.
[1], https://patchwork.kernel.org/patch/2160771/
Thanks, -- Ming Lei
| |