All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Subject: Re: [PATCH 5.10.y 1/9] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
Date: Tue, 28 Jul 2026 12:09:56 -0400	[thread overview]
Message-ID: <20260728155654.stable-0002@kernel.org> (raw)
In-Reply-To: <20260724101342.16000-1-socketcan@hartkopp.net>

> -		sprintf(bo->procname, "%lu", sock_i_ino(sk));
> +		sprintf(bo->procname, "%llu", sock_i_ino(sk));

This hunk is not part of 68973f9db761 ("can: bcm: defer rx_op deallocation
to workqueue to fix thrtimer UAF").  It belongs to 0fe27e598592 ("net:
change sock.sk_ino and sock_i_ino() to u64"), which is not in 5.10.y -
sock_i_ino() still returns unsigned long there.  The result is a -Wformat
warning (a hard build failure under CONFIG_WERROR) and, on 32-bit arches, a
/proc/net/can-bcm/ file name built partly out of adjacent stack.

Patches 2/9 to 9/9 look fine on both 5.10.y and 5.15.y.  Could you respin
1/9 without that hunk?  I'll take the full series once it's in.

-- 
Thanks,
Sasha

  parent reply	other threads:[~2026-07-28 16:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 15:12 FAILED: patch "[PATCH] can: bcm: defer rx_op deallocation to workqueue to fix" failed to apply to 5.10-stable tree gregkh
2026-07-24  8:35 ` [PATCH 1/9] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Oliver Hartkopp
2026-07-24 10:13 ` [PATCH 5.10.y " Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 2/9] can: bcm: add locking when updating filter and timer values Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 3/9] can: bcm: fix CAN frame rx/tx statistics Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 4/9] can: bcm: extend bcm_tx_lock usage for data and timer updates Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 5/9] can: bcm: validate frame length in bcm_rx_setup() for RTR replies Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 6/9] can: bcm: add missing device refcount for CAN filter removal Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 7/9] can: bcm: fix stale rx/tx ops after device removal Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 8/9] can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() Oliver Hartkopp
2026-07-24 10:13   ` [PATCH 5.10.y 9/9] can: bcm: track a single source interface for ANYDEV timeout/throttle ops Oliver Hartkopp
2026-07-24 10:38   ` [PATCH 5.10.y 1/9] can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Greg KH
2026-07-24 10:43     ` Oliver Hartkopp
2026-07-28 16:09   ` Sasha Levin [this message]
2026-07-28 16:45     ` Oliver Hartkopp

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=20260728155654.stable-0002@kernel.org \
    --to=sashal@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=socketcan@hartkopp.net \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.