drivers/base/swnode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
From: Mike Isely <mike.isely@cobaltdigital.com>
Correct issue in drivers/base/swnode.c that can lead to use-after-free
due to kobject reference counting error, which itself is due to
incorrect behavior with the "managed" struct swnode flag in
circumstances involving child struct device instances where the parent
struct device is managing a struct swnode.
Use-after-free in this case led to an Oops and a subsequent kernel
memory leak, but realistically it's kernel heap corruption, so any
manner of chaos can result, if left unaddressed.
This was detected in kernel 6.12, verified also in kernel 6.6. Visual
inspection in 6.19.3 source (the latest as of right now) shows the
same issue. The nearly trivial fix was verified in 6.12. While this
patches against 6.19.3, IMHO this is a candidate for all LTS kernels.
Mike Isely (1):
sofware node: Only the managing device can unreference managed
software node
drivers/base/swnode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.47.3
On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote: > Correct issue in drivers/base/swnode.c that can lead to use-after-free > due to kobject reference counting error, which itself is due to > incorrect behavior with the "managed" struct swnode flag in > circumstances involving child struct device instances where the parent > struct device is managing a struct swnode. > > Use-after-free in this case led to an Oops and a subsequent kernel > memory leak, but realistically it's kernel heap corruption, so any > manner of chaos can result, if left unaddressed. > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual > inspection in 6.19.3 source (the latest as of right now) shows the The latest is v7.0-rc1 as of time of the topic message. > same issue. The nearly trivial fix was verified in 6.12. While this > patches against 6.19.3, IMHO this is a candidate for all LTS kernels. Thanks for the contribution, usually for a single patch there is no need in cover letter. The comment block can handle this (the place after cutter '---' line in the message with a patch). -- With Best Regards, Andy Shevchenko
On Wed, 25 Feb 2026, Andy Shevchenko wrote: > On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote: > > > Correct issue in drivers/base/swnode.c that can lead to use-after-free > > due to kobject reference counting error, which itself is due to > > incorrect behavior with the "managed" struct swnode flag in > > circumstances involving child struct device instances where the parent > > struct device is managing a struct swnode. > > > > Use-after-free in this case led to an Oops and a subsequent kernel > > memory leak, but realistically it's kernel heap corruption, so any > > manner of chaos can result, if left unaddressed. > > > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual > > inspection in 6.19.3 source (the latest as of right now) shows the > > The latest is v7.0-rc1 as of time of the topic message. I actually meant the latest release. Guess I should have checked the latest release candidate on the off-chance that it might have been addressed. > > > same issue. The nearly trivial fix was verified in 6.12. While this > > patches against 6.19.3, IMHO this is a candidate for all LTS kernels. > > Thanks for the contribution, usually for a single patch there is no need > in cover letter. The comment block can handle this (the place after cutter > '---' line in the message with a patch). Yeah, a separate cover letter is overkill, but I was just following a process here. -Mike isely@pobox.com
On Wed, Feb 25, 2026 at 12:59:56PM -0600, Mike Isely wrote: > On Wed, 25 Feb 2026, Andy Shevchenko wrote: > > On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote: ... > > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual > > > inspection in 6.19.3 source (the latest as of right now) shows the > > > > The latest is v7.0-rc1 as of time of the topic message. > > I actually meant the latest release. Guess I should have checked the > latest release candidate on the off-chance that it might have been > addressed. It is probably not, but the idea to check against latest tag in the vanilla repository. v6.19.3 is not even vanilla, it's stable kernel. > > > same issue. The nearly trivial fix was verified in 6.12. While this > > > patches against 6.19.3, IMHO this is a candidate for all LTS kernels. > > > > Thanks for the contribution, usually for a single patch there is no need > > in cover letter. The comment block can handle this (the place after cutter > > '---' line in the message with a patch). > > Yeah, a separate cover letter is overkill, but I was just following a > process here. What process? I think we have that somewhere in the documentation that cover letter for a single patch is not needed... -- With Best Regards, Andy Shevchenko
On Wed, 25 Feb 2026, Andy Shevchenko wrote: > On Wed, Feb 25, 2026 at 12:59:56PM -0600, Mike Isely wrote: > > On Wed, 25 Feb 2026, Andy Shevchenko wrote: > > > On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote: > > ... > > > > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual > > > > inspection in 6.19.3 source (the latest as of right now) shows the > > > > > > The latest is v7.0-rc1 as of time of the topic message. > > > > I actually meant the latest release. Guess I should have checked the > > latest release candidate on the off-chance that it might have been > > addressed. > > It is probably not, but the idea to check against latest tag in the vanilla > repository. v6.19.3 is not even vanilla, it's stable kernel. I tend to stick with the latest kernel that is NOT a release candidate when building random things here regardless of the term used and that's still 6.19.3. But for verifying a patch, yes I should have at least taken a closer look at 7.0-rc1. > > > > > same issue. The nearly trivial fix was verified in 6.12. While this > > > > patches against 6.19.3, IMHO this is a candidate for all LTS kernels. > > > > > > Thanks for the contribution, usually for a single patch there is no need > > > in cover letter. The comment block can handle this (the place after cutter > > > '---' line in the message with a patch). > > > > Yeah, a separate cover letter is overkill, but I was just following a > > process here. > > What process? I think we have that somewhere in the documentation that cover > letter for a single patch is not needed... Documentation/process/submitting-patches.rst in the kernel sources, or https://docs.kernel.org/process/submitting-patches.html -Mike isely@pobox.com
On Wed, Feb 25, 2026 at 01:48:04PM -0600, Mike Isely wrote: > On Wed, 25 Feb 2026, Andy Shevchenko wrote: > > On Wed, Feb 25, 2026 at 12:59:56PM -0600, Mike Isely wrote: > > > On Wed, 25 Feb 2026, Andy Shevchenko wrote: > > > > On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote: ... > > > > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual > > > > > inspection in 6.19.3 source (the latest as of right now) shows the > > > > > > > > The latest is v7.0-rc1 as of time of the topic message. > > > > > > I actually meant the latest release. Guess I should have checked the > > > latest release candidate on the off-chance that it might have been > > > addressed. > > > > It is probably not, but the idea to check against latest tag in the vanilla > > repository. v6.19.3 is not even vanilla, it's stable kernel. > > I tend to stick with the latest kernel that is NOT a release candidate > when building random things here regardless of the term used and that's > still 6.19.3. But for verifying a patch, yes I should have at least > taken a closer look at 7.0-rc1. The logical requirement for a new contribution is to build changes against current or next cycle. Hence only two kernels have interest to us: - latest tag in vanilla (v7.0-rc1 as of today) - latest tag in Linux Next (whatever day it is) > > > > > same issue. The nearly trivial fix was verified in 6.12. While this > > > > > patches against 6.19.3, IMHO this is a candidate for all LTS kernels. > > > > > > > > Thanks for the contribution, usually for a single patch there is no need > > > > in cover letter. The comment block can handle this (the place after cutter > > > > '---' line in the message with a patch). > > > > > > Yeah, a separate cover letter is overkill, but I was just following a > > > process here. > > > > What process? I think we have that somewhere in the documentation that cover > > letter for a single patch is not needed... > > Documentation/process/submitting-patches.rst in the kernel sources, or > https://docs.kernel.org/process/submitting-patches.html Yes, it maybe not so clear but it actually tells you to choose between two: - vanilla (latest tag), OR - dedicated tree "for-next" (most use this, but some use other name for the branch for the next cycle). -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.