From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: CVE-2021-47288: media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
Date: Tue, 21 May 2024 16:35:22 +0200 [thread overview]
Message-ID: <2024052122-CVE-2021-47288-ffb4@gregkh> (raw)
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &com.cmd.ConfigureBuffers.config,
when calling memcpy().
This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy().
The Linux kernel CVE team has assigned CVE-2021-47288 to this issue.
Affected and fixed versions
===========================
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 4.4.277 with commit 4487b968e5ea
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 4.9.277 with commit c6ddeb63dd54
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 4.14.241 with commit e818f2ff6485
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 4.19.199 with commit ec731c6ef564
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 5.4.136 with commit e617fa62f6cf
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 5.10.54 with commit e991457afdcb
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 5.13.6 with commit b9a178f189bb
Issue introduced in 2.6.34 with commit dae52d009fc9 and fixed in 5.14 with commit 8d4abca95ecc
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-2021-47288
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/pci/ngene/ngene-core.c
drivers/media/pci/ngene/ngene.h
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/4487b968e5eacd02c493303dc2b61150bb7fe4b2
https://git.kernel.org/stable/c/c6ddeb63dd543b5474b0217c4e47538b7ffd7686
https://git.kernel.org/stable/c/e818f2ff648581a6c553ae2bebc5dcef9a8bb90c
https://git.kernel.org/stable/c/ec731c6ef564ee6fc101fc5d73e3a3a953d09a00
https://git.kernel.org/stable/c/e617fa62f6cf859a7b042cdd6c73af905ff8fca3
https://git.kernel.org/stable/c/e991457afdcb5f4dbc5bc9d79eaf775be33e7092
https://git.kernel.org/stable/c/b9a178f189bb6d75293573e181928735f5e3e070
https://git.kernel.org/stable/c/8d4abca95ecc82fc8c41912fa0085281f19cc29f
reply other threads:[~2024-05-21 14:37 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=2024052122-CVE-2021-47288-ffb4@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 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.