From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: CVE-2024-26791: btrfs: dev-replace: properly validate device names
Date: Thu, 4 Apr 2024 10:23:08 +0200 [thread overview]
Message-ID: <2024040400-CVE-2024-26791-1002@gregkh> (raw)
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
btrfs: dev-replace: properly validate device names
There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links).
The Linux kernel CVE team has assigned CVE-2024-26791 to this issue.
Affected and fixed versions
===========================
Fixed in 4.19.309 with commit 11d7a2e429c0
Fixed in 5.4.271 with commit c6652e20d7d7
Fixed in 5.10.212 with commit 2886fe308a83
Fixed in 5.15.151 with commit ab2d68655d0f
Fixed in 6.1.81 with commit f590040ce2b7
Fixed in 6.6.21 with commit b1690ced4d2d
Fixed in 6.7.9 with commit 343eecb4ff49
Fixed in 6.8 with commit 9845664b9ee4
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-2024-26791
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:
fs/btrfs/dev-replace.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/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
reply other threads:[~2024-04-04 8:23 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=2024040400-CVE-2024-26791-1002@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).