All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-89741: Revert "media: v4l2-dev: fix error handling in __video_register_device()"
Date: Fri, 11 Sep 2026 21:47:10 +0200	[thread overview]
Message-ID: <2026091104-CVE-2026-89741-1937@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

Revert "media: v4l2-dev: fix error handling in __video_register_device()"

This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.

The intentions of that patch were good, but it doesn't work.

The idea is that if device_register fails, you have to do a put_device
to let the ref counter release resources.

However, the V4L2 API says that if video_register_device() fails, then
you have to call video_device_release(), which kfree()s the video_device
struct.

But the put_device() will already have freed the struct, so you end
up in a double-free scenario.

There is not really a good way of fixing this without breaking
video_register_device() into two parts, one that initializes everything,
and one that does the actual device_register, and then converting all
V4L2 drivers to this new model.

That is a massive job, and it is very unlikely that device_register
will fail.

So rather than ending up in a double-free scenario, just revert this
patch, and in that case we'll have a small memory leak. Which is a lot
more robust.

The Linux kernel CVE team has assigned CVE-2026-89741 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12.35 with commit 2429bb9fad88c8fa84c4956b0a21cf5afe5e92b7 and fixed in 6.12.109 with commit 712ca1cf756de2557a116e0df55791bac0c9f99e
	Issue introduced in 6.16 with commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a and fixed in 6.18.50 with commit aad08b5f67d2a8116e1a00bce2611c1513b10bce
	Issue introduced in 6.16 with commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a and fixed in 7.2.4 with commit ce792b94e03882108019ba996c1a7c4d4e09be2c
	Issue introduced in 6.16 with commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a and fixed in 7.3-rc1 with commit e7600f5cee5de14065f950807931d6e6d40fb2d7
	Issue introduced in 5.4.295 with commit ee141706e701356dda41c6fed9ee18bf427c28e3
	Issue introduced in 5.10.239 with commit e5c8e62ae551e0ad2e15412aa0c57c2856d59677
	Issue introduced in 5.15.186 with commit 8b451a9a46f2bfc510e6d5c2492df91647586184
	Issue introduced in 6.1.142 with commit b6be1f5633eae200af2527e9eeb7f51be5739b0f
	Issue introduced in 6.6.95 with commit ae7b143e05b36fc69d6571751855946cc45064c6
	Issue introduced in 6.15.4 with commit 4451412739ed33a49b34624299394ee575116d0c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89741
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/media/v4l2-core/v4l2-dev.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/712ca1cf756de2557a116e0df55791bac0c9f99e
	https://git.kernel.org/stable/c/aad08b5f67d2a8116e1a00bce2611c1513b10bce
	https://git.kernel.org/stable/c/ce792b94e03882108019ba996c1a7c4d4e09be2c
	https://git.kernel.org/stable/c/e7600f5cee5de14065f950807931d6e6d40fb2d7

                 reply	other threads:[~2026-09-11 20:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=2026091104-CVE-2026-89741-1937@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@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.