fanotify: surprising chain reaction -> deadlock

fanotify: surprising chain reaction -> deadlock

[Marko Rauhamaa]

Just an observation of an fanotify complication...

We have just managed to analyze an interesting vicious circle
(simplified):

 * disable IPv6 in the kernel

 * start a file monitor

 * during its initialization, the file monitor

    1. marks file systems with OPEN_PERM

    2. calls socket(PF_INET6)

 * the kernel executes this piece of code (socket.c):

#ifdef CONFIG_MODULES
	/* Attempt to load a protocol module if the find failed.
	 *
	 * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
	 * requested real, full-featured networking support upon configuration.
	 * Otherwise module support will break!
	 */
	if (rcu_access_pointer(net_families[family]) == NULL)
		request_module("net-pf-%d", family);
#endif

 * request_module spawns "modprobe" in the user space

 * opening "modprobe" is blocked by OPEN_PERM; however, the file monitor
   is still blocked in the socket(2) system call and can't release the
   "modprobe" process

I'm not sure if there is a bug somewhere here but a surprising
interaction nonetheless.


Marko

Re: fanotify: surprising chain reaction -> deadlock

[Jan Kara]

Hello,

On Wed 27-03-19 14:08:51, Marko Rauhamaa wrote:
> Just an observation of an fanotify complication...
> 
> We have just managed to analyze an interesting vicious circle
> (simplified):
> 
>  * disable IPv6 in the kernel
> 
>  * start a file monitor
> 
>  * during its initialization, the file monitor
> 
>     1. marks file systems with OPEN_PERM
> 
>     2. calls socket(PF_INET6)
> 
>  * the kernel executes this piece of code (socket.c):
> 
> #ifdef CONFIG_MODULES
> 	/* Attempt to load a protocol module if the find failed.
> 	 *
> 	 * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
> 	 * requested real, full-featured networking support upon configuration.
> 	 * Otherwise module support will break!
> 	 */
> 	if (rcu_access_pointer(net_families[family]) == NULL)
> 		request_module("net-pf-%d", family);
> #endif
> 
>  * request_module spawns "modprobe" in the user space
> 
>  * opening "modprobe" is blocked by OPEN_PERM; however, the file monitor
>    is still blocked in the socket(2) system call and can't release the
>    "modprobe" process
> 
> I'm not sure if there is a bug somewhere here but a surprising
> interaction nonetheless.

Yeah. Everything works as it should but I agree it is rather surprising. It
is difficult to design process processing fanotify permission events that
does not deadlock...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR