Re: [PATCH net 03/19] can: raw: add locking for raw flags bitfield

[email protected] Fri, 17 Jul 2026 16:45:58 +0000
Newsgroups org.kernel.vger.linux-can
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Holding `rtnl_lock()` across user-space memory copies enables a system-wide Denial of Service.
--

--- Patch [3]: [PATCH net 03/19] can: raw: add locking for raw flags bitfield ---
commit 64cfa8c3c841a4b23931e54d2dfb767381bcd986
Author: Oliver Hartkopp <[email protected]>

can: raw: add locking for raw flags bitfield

This commit integrates separate integer values into a single bitfield and
adds locking to prevent concurrent access during read-modify-write
operations in raw_setsockopt. It introduces a raw_setsockopt_locked
function wrapped by a new raw_setsockopt to handle the locking.

Closes: https://lore.kernel.org/linux-can/[email protected]/
Link: https://patch.msgid.link/[email protected]

> diff --git a/net/can/raw.c b/net/can/raw.c
> index a26942e78e688..82d9c0499c95f 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c

[ ... ]

> @@ -769,6 +743,26 @@ static int raw_setsockopt(struct socket *sock, int level, int optname,
>  	return err;
>  }
>  
> +static int raw_setsockopt(struct socket *sock, int level, int optname,
> +			  sockptr_t optval, unsigned int optlen)
> +{
> +	struct sock *sk = sock->sk;
> +	int err;
> +
> +	if (level != SOL_CAN_RAW)
> +		return -EINVAL;
> +
> +	rtnl_lock();
> +	lock_sock(sk);
> +
> +	err = raw_setsockopt_locked(sock, optname, optval, optlen);

[Severity: High]
Does holding rtnl_lock() across raw_setsockopt_locked() allow a system-wide
Denial of Service?

Inside raw_setsockopt_locked(), user-space memory copies are performed
before rtnl_lock() was historically taken:

	case CAN_RAW_FILTER:
		...
		if (count > 1) {
			filter = memdup_sockptr(optval, optlen);
			...
		} else if (count == 1) {
			if (copy_from_sockptr(&sfilter, optval, sizeof(sfilter)))
				...
		}

Could a local user pass a memory pointer backed by userfaultfd or a slow FUSE
mount, intentionally stalling the page fault during memdup_sockptr() or
copy_from_sockptr(), and freeze network configuration for the whole system by
holding the global rtnl_lock?

It seems the isotp.c example cited in the commit message only takes
lock_sock() in its wrapper, not rtnl_lock().

> +
> +	release_sock(sk);
> +	rtnl_unlock();
> +
> +	return err;
> +}

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3