On 02/02/2023 15:18, Tudor Cretu wrote:
-long pipe_fcntl(struct file *file, unsigned int cmd, unsigned long arg) +long pipe_fcntl(struct file *file, unsigned int cmd, unsigned int arg)
Hi Luca,
Please, correct me if I'm wrong, but this function seems to be called for both F_SETPIPE_SZ and F_GETPIPE_SZ. The issue is the type of arg expected for F_GETPIPE_SZ is void (no argument). So in the case of F_GETPIPE_SZ, the kernel accesses undefined bytes even with this change. My first idea is to separate the handler into two, one for F_SETPIPE_SZ and one for F_GETPIPE_SZ. I haven't looked in detail to see if that would cause issues, so feel free to explore the issue and other options as well.
Thanks, Tudor
On a second thought, I don't think this would cause any issue because, as you mentioned, the F_GETPIPE_SZ doesn't use arg. While I still prefer separate handlers given that one uses arg, and the other doesn't, I think it's fine to leave it like this as well. So feel free to ignore this comment, as well as the one for F_{ADD,GET}_SEALS. Maybe someone else can chime in on this with a stronger argument if they see fit.
FWIW I don't think it's worth bothering, passing an invalid argument around and not using it is not a problem (otherwise you'd have a problem with do_fcntl() itself).
Kevin