On Tue, Nov 16, 2021 at 08:57:09PM +0300, Dan Carpenter wrote:
> On Tue, Nov 16, 2021 at 05:21:34PM +0200, Amir Goldstein wrote:
> > On Tue, Nov 16, 2021 at 1:45 PM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> > >
> > > Hello Amir Goldstein,
> > >
> > > The patch cacfb956d46e: "fanotify: record name info for
> > > FAN_DIR_MODIFY event" from Mar 19, 2020, leads to the following
> > > Smatch static checker warning:
> > >
> > > fs/notify/fanotify/fanotify_user.c:401 copy_fid_info_to_user()
> > > error: we previously assumed 'fh' could be null (see line 362)
> > >
> > > fs/notify/fanotify/fanotify_user.c
> > > 354 static int copy_fid_info_to_user(__kernel_fsid_t *fsid, struct fanotify_fh *fh,
> > > 355 int info_type, const char *name,
> > > 356 size_t name_len,
> > > 357 char __user *buf, size_t count)
> > > 358 {
> > > 359 struct fanotify_event_info_fid info = { };
> > > 360 struct file_handle handle = { };
> > > 361 unsigned char bounce[FANOTIFY_INLINE_FH_LEN], *fh_buf;
> > > 362 size_t fh_len = fh ? fh->len : 0;
> > > ^^^^^^^^^^^^^
> > > The patch adds a check for in "fh" is NULL
> > >
> > > 363 size_t info_len = fanotify_fid_info_len(fh_len, name_len);
> > > 364 size_t len = info_len;
> > > 365
> > > 366 pr_debug("%s: fh_len=%zu name_len=%zu, info_len=%zu, count=%zu\n",
> > > 367 __func__, fh_len, name_len, info_len, count);
> > > 368
> >
> > Upstream has these two lines:
> > if (!fh_len)
> > return 0;
> >
> > Which diffuses the reported bug.
> > Where did those lines go?
>
> I'm not sure, I suspected this might be a merge issue.
Oh, duh. I'm using linux-next. Probably that's relevant information.
regards,
dan carpenter
