Re: [PATCH net v4] atm: mpoa: Fix UAF on qos_head list in procfs

[Simon Horman <horms@kernel.org>]

On Tue, Dec 16, 2025 at 09:09:10PM +0900, Minseong Kim wrote:
> /proc/net/atm/mpc read-side iterates qos_head without synchronization,
> while write-side can delete and free entries concurrently, leading to
> use-after-free.
> 
> Protect qos_head with a mutex and ensure procfs search+delete operations
> are serialized under the same lock.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Minseong Kim <ii4gsp@gmail.com>

...

> @@ -1521,8 +1525,11 @@ static void __exit atm_mpoa_cleanup(void)
>  		mpc = tmp;
>  	}
>  
> +	mutex_lock(&qos_mutex);
>  	qos = qos_head;
>  	qos_head = NULL;
> +	mutex_unlock(&qos_mutex);

I don't think this is necessary.

mpc_proc_clean() is called earlier in atm_mpoa_cleanup().  So I don't think
any accesses to the procfs callbacks can be occurring at this point. So
there is no need to guard against that.


Conversely the following call chain accesses, qos_head, and uses an entry
if found there. But there doesn't seem to be protection for concurrent
access (or removal) from procfs.

MPOA_res_reply_rcvd()->check_qos_and_open_shortcut->atm_mpoa_search_qos()

In this case I'm concerned that extending the current locking approach may
result in poor behaviour if procfs holds qos_mutex for an extended period.


And I think that there is also a concurrency issue with
access to qos_head in the following call chain.

mpc_show()->atm_mpoa_disp_qos()

...

-- 
pw-bot: changes-requested