From: sashiko-bot@kernel.org
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Vincent Mailhol" <mailhol@kernel.org>,
linux-can@vger.kernel.org,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>
Subject: Re: [PATCH net 03/19] can: raw: add locking for raw flags bitfield
Date: Fri, 17 Jul 2026 16:45:58 +0000 [thread overview]
Message-ID: <20260717164558.E1C0D1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260716155528.809908-4-mkl@pengutronix.de>
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 <socketcan@hartkopp.net>
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/20260503112200.22727-1-eulgyukim@snu.ac.kr/
Link: https://patch.msgid.link/20260504111928.41856-1-socketcan@hartkopp.net
> 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/20260716155528.809908-1-mkl@pengutronix.de?part=3
next prev parent reply other threads:[~2026-07-17 16:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 15:47 [PATCH net 0/19] pull-request: can 2026-07-16 Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 01/19] can: vxcan: Kconfig: fix description stating no local echo provided Marc Kleine-Budde
2026-07-17 9:50 ` patchwork-bot+netdevbpf
2026-07-16 15:47 ` [PATCH net 02/19] can: esd_usb: kill anchored URBs before freeing netdevs Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 03/19] can: raw: add locking for raw flags bitfield Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot [this message]
2026-07-16 15:47 ` [PATCH net 04/19] can: j1939: fix lockless local-destination check Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 05/19] can: peak: Modification of references to email accounts being deleted Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 06/19] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 07/19] can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure Marc Kleine-Budde
2026-07-17 16:46 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 08/19] can: bcm: add locking when updating filter and timer values Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 09/19] can: bcm: fix CAN frame rx/tx statistics Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 10/19] can: bcm: add missing rcu list annotations and operations Marc Kleine-Budde
2026-07-17 16:45 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 11/19] can: bcm: extend bcm_tx_lock usage for data and timer updates Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 12/19] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 13/19] can: bcm: add missing device refcount for CAN filter removal Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 14/19] can: bcm: fix stale rx/tx ops after device removal Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 15/19] can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() Marc Kleine-Budde
2026-07-17 16:46 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 16/19] can: bcm: track a single source interface for ANYDEV timeout/throttle ops Marc Kleine-Budde
2026-07-16 15:47 ` [PATCH net 17/19] can: isotp: use unconditional synchronize_rcu() in isotp_release() Marc Kleine-Budde
2026-07-17 16:46 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 18/19] can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER Marc Kleine-Budde
2026-07-17 16:46 ` sashiko-bot
2026-07-16 15:47 ` [PATCH net 19/19] can: isotp: serialize TX state transitions under so->rx_lock Marc Kleine-Budde
2026-07-17 16:46 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260717164558.E1C0D1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox