Possible data race on file->f_mode between __fget() and generic_fadvise()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi VFS developers,

There might exists cases where file->f_mode may race in __fget() and
generic_fadvise().

[Setup]
mkdir(dir_foo, 0777) = 0;
open(dir_foo, 0x10000, 0777) = 3;
dup2(3, 199) = 199;

[Thread 1]: mkdirat(199, dir_foo, 0576) = 0;
[Thread 2]: fadvise64(3, 140517292505364, 155, 0x2) = 0;

[Thread 1: SYS_mkdirat]
__do_sys_mkdirat
  do_mkdirat
    user_path_create
      filename_create
        filename_parentat
          path_parentat
            path_init
              fdget_raw
                __fdget_raw
                  __fget_light
                    __fget
                      [READ] if (file->f_mode & mask)

[Thread 2: SYS_fadvise64]
__do_sys_fadvise64
  ksys_fadvise64_64
    vfs_fadvise
      generic_fadvise
        [WRITE] file->f_mode &= ~FMODE_RANDOM;

However, in this particular case, there is no issues caused as the
mask passed in __fget() is always 0 and hence, does not matter what
the [WRITE] statement is doing.

But just in case there may be other cases where the mask is not 0, it
may leads to weird situations and I am posting this issue here for
more visibility. Feel free to comment on its validity.

Best Regards,
Meng



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux