summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorChirantan Ekbote <chirantan@chromium.org>2020-07-14 19:26:39 +0900
committerMiklos Szeredi <mszeredi@redhat.com>2020-07-15 14:18:20 +0200
commit31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 (patch)
treecc8d2ed44516dd759324d0452f2ccb880b360a70 /include
parent7779b047a57f6824a43d0e1f70de2741b7426b9d (diff)
fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS
The ioctl encoding for this parameter is a long but the documentation says it should be an int and the kernel drivers expect it to be an int. If the fuse driver treats this as a long it might end up scribbling over the stack of a userspace process that only allocated enough space for an int. This was previously discussed in [1] and a patch for fuse was proposed in [2]. From what I can tell the patch in [2] was nacked in favor of adding new, "fixed" ioctls and using those from userspace. However there is still no "fixed" version of these ioctls and the fact is that it's sometimes infeasible to change all userspace to use the new one. Handling the ioctls specially in the fuse driver seems like the most pragmatic way for fuse servers to support them without causing crashes in userspace applications that call them. [1]: https://lore.kernel.org/linux-fsdevel/20131126200559.GH20559@hall.aurel32.net/T/ [2]: https://sourceforge.net/p/fuse/mailman/message/31771759/ Signed-off-by: Chirantan Ekbote <chirantan@chromium.org> Fixes: 59efec7b9039 ("fuse: implement ioctl support") Cc: <stable@vger.kernel.org> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions