On Tue, Nov 27, 2018 at 3:06 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Tue, Nov 27, 2018 at 2:05 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: >> >> On Mon, 2018-11-26 at 10:38 -0600, Goldwyn Rodrigues wrote: >> > A file can be opened with open(O_WRONLY | O_RDWR), so a FMORE_READ >> > will not be set, and overlayfs will consider another copy_up() on the same >> > file leading to a deadlock on mnt_want_write(). Fix it by masking >> > O_RDWR while opening the file in read-only mode. >> >> Shouldn't the open itself fail if both O_WRONLY and O_RDWR are >> specified? >> > > Well, open doesn't fail, so what can you do? prove that no app out there > is using this bizarre flag combination and return -EINVAL? > You can try... > > BTW, the freakish thing about O_WRONLY | O_RDWR, is that it actually > translates to !f->f_mode & FMODE_READ && !f->f_mode & FMODE_WRITE: > OPEN_FMODE(1|2) = (3+1) & 3 = 0 > > It would make more sense if O_WRONLY | O_RDWR would have the > same result as O_RDWR, which is exactly what happens with > ACC_MODE(flags) in build_open_flags(). > build_open_flags() would be a good place to check and fix this abnormality. Good idea. Breaking userspace is not an option, but isolating lower kernel levels from this sounds reasonable.
