Re: [PATCH] fsnotify: don't put user context if it was never assigned

[Heinrich Schuchardt]

Hello Sasha,

I have CCed Jan, because he has been the only one working on this file 
in the last 18 months.

A failure path in which group->inotify_data.user is not yet assigned 
starts here:

static struct fsnotify_group *inotify_new_group(unsigned int max_events)
{
...
	oevent = kmalloc(sizeof(struct inotify_event_info), GFP_KERNEL);
	if (unlikely(!oevent)) {
		fsnotify_destroy_group(group);
		return ERR_PTR(-ENOMEM);
	}

So your check
  if (group->inotify_data.user)
is reasonable.

3.17.0-rc3 compiles with the patch applied.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@xxxxxx>

@Andrew
Please, add the patch to the mm-tree.

Best regards

Heinrich Schuchardt

On 29.07.2014 15:25, Sasha Levin wrote:
> On some failure paths we may attempt to free user context even
> if it wasn't assigned yet. This will cause a NULL ptr deref
> and a kernel BUG.
>
> Signed-off-by: Sasha Levin <sasha.levin@xxxxxxxxxx>
> ---
>   fs/notify/inotify/inotify_fsnotify.c |    6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/notify/inotify/inotify_fsnotify.c b/fs/notify/inotify/inotify_fsnotify.c
> index 43ab1e1..9c8187e 100644
> --- a/fs/notify/inotify/inotify_fsnotify.c
> +++ b/fs/notify/inotify/inotify_fsnotify.c
> @@ -165,8 +165,10 @@ static void inotify_free_group_priv(struct fsnotify_group *group)
>   	/* ideally the idr is empty and we won't hit the BUG in the callback */
>   	idr_for_each(&group->inotify_data.idr, idr_callback, group);
>   	idr_destroy(&group->inotify_data.idr);
> -	atomic_dec(&group->inotify_data.user->inotify_devs);
> -	free_uid(group->inotify_data.user);
> +	if (group->inotify_data.user) {
> +		atomic_dec(&group->inotify_data.user->inotify_devs);
> +		free_uid(group->inotify_data.user);
> +	}
>   }
>
>   static void inotify_free_event(struct fsnotify_event *fsn_event)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/