From: "Danilo Krummrich" <dakr@kernel.org>
To: "Linus Torvalds" <torvalds@linux-foundation.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Saravana Kannan" <saravanak@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
<driver-core@lists.linux.dev>, <rust-for-linux@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Driver core fixes for 7.0-rc5
Date: Sun, 22 Mar 2026 13:30:49 +0100 [thread overview]
Message-ID: <DH9B9DJ5EPIE.2019ZR2OA8ZR9@kernel.org> (raw)
In-Reply-To: <CAHk-=wjA2mOM=hCGBiS9r7+5KCmTd3KMrTTZQsE=rRLqqKMTyg@mail.gmail.com>
On Sun Mar 22, 2026 at 1:08 AM CET, Linus Torvalds wrote:
> I'm not convinced there are advantages to going through individual
> trees - these are just buses working around driver core interface
> issues, not some "bus X does bus X things".
I figured it could be a bit safer to let subsystems pick things up themselves at
their own pace, as two of those stand out a bit.
SPI and AP explicitly print "\n" when driver_override is not set, whereas all
other buses always pass the pointer directly to sysfs_emit(), which results in
"(null)\n" instead.
AP also has a custom driver_override counter, which is updated in the sysfs
store() callback.
> That said, I'm also not convinced this is all really -rc material in
> the first place. This issue is neither new nor does the UAF seem to be
> triggerable in any actual realistic scenario, and requires root
> privileges to trigger even in the unrealistic case.
I don't disagree; the reason I sent this regardless is that we already had a
(simpler) fix in place that we reverted in -rc3, so I figured it is not
unreasonable to follow this up right away.
I think none of the above are strong reasons though (i.e. the fact we already
had a fix in place does not make the underlying issue any more urgent).
That said, deferring until the merge window seems fair.
- Danilo
next prev parent reply other threads:[~2026-03-22 12:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 22:46 [GIT PULL] Driver core fixes for 7.0-rc5 Danilo Krummrich
2026-03-22 0:08 ` Linus Torvalds
2026-03-22 12:30 ` Danilo Krummrich [this message]
2026-03-22 18:04 ` pr-tracker-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=DH9B9DJ5EPIE.2019ZR2OA8ZR9@kernel.org \
--to=dakr@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@kernel.org \
--cc=torvalds@linux-foundation.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.