Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for CVE-2023-5178 FIPS 9 VULN-6747 #31

Conversation

gvrose8192
Copy link
Collaborator

jira VULN-6747
cve CVE-2023-5178
commit-author Sagi Grimberg sagi@grimberg.me
commit d920abd

From Alon:
"Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel, a malicious user can cause a UAF and a double free, which may lead to RCE (may also lead to an LPE in case the attacker already has local privileges)."

Hence, when a queue initialization fails after the ahash requests are allocated, it is guaranteed that the queue removal async work will be called, hence leave the deallocation to the queue removal.

Also, be extra careful not to continue processing the socket, so set queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.

Cc: stable@vger.kernel.org
Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
Tested-by: Alon Zahavi <zahavi.alon@gmail.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>

(cherry picked from commit d920abd)
Signed-off-by: Greg Rose g.v.rose@ciq.com

**Builds and Installs:**
`/home/g.v.rose/prj/kernel-build-tmp
CLEAN vmlinux.symvers modules-only.symvers modules.builtin modules.builtin.modinfo
CLEAN scripts/basic
CLEAN scripts/genksyms
CLEAN scripts/kconfig
CLEAN scripts/mod
CLEAN scripts/selinux/genheaders
CLEAN scripts/selinux/mdp
CLEAN scripts
CLEAN include/config include/generated arch/x86/include/generated .config .config.old .version Module.symvers certs/signing_key.pem certs/signing_key.x509 certs/x509.genkey
[TIMER]{MRPROPER}: 13s
x86_64 architecture detected, copying config
'configs/kernel-5.14.0-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-gvrose_fips-9-compliant_5.14.0-284.30.1"
Making olddefconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf

configuration written to .config

Starting Build
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
`

[SNIP]

STRIP /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+/kernel/sound/xen/snd_xen_front.ko SIGN /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+/kernel/sound/xen/snd_xen_front.ko INSTALL /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+/kernel/virt/lib/irqbypass.ko STRIP /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+/kernel/virt/lib/irqbypass.ko SIGN /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+/kernel/virt/lib/irqbypass.ko DEPMOD /lib/modules/5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+ [TIMER]{MODULES}: 63s Making Install sh ./arch/x86/boot/install.sh \ 5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+ arch/x86/boot/bzImage \ System.map "/boot" [TIMER]{INSTALL}: 22s Checking kABI Checking kABI kABI check passed Setting Default Kernel to /boot/vmlinuz-5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+ and Index to 0 Hopefully Grub2.0 took everything ... rebooting after time metrices [TIMER]{MRPROPER}: 13s [TIMER]{BUILD}: 864s [TIMER]{MODULES}: 63s [TIMER]{INSTALL}: 22s [TIMER]{TOTAL} 969s Rebooting in 10 seconds

Boots
[g.v.rose@rocky92-lts-base ~]$ uname -a Linux rocky92-lts-base 5.14.0-gvrose_fips-9-compliant_5.14.0-284.30.1+ #1 SMP PREEMPT_DYNAMIC Wed Dec 18 11:35:12 PST 2024 x86_64 x86_64 x86_64 GNU/Linux
Before and after Kernel selftests

Nothing remarkable.

kernel-selftests-before.log
kernel-selftests-after.log

I skipped running the kernel selftests with lockdep and kmemleak enabled because this patch is already well tested in several of our other kernels. If asked to I can go ahead and do that, but I don't feel it's necessary.

jira VULN-6747
cve CVE-2023-5178
commit-author Sagi Grimberg <sagi@grimberg.me>
commit d920abd

From Alon:
"Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel,
a malicious user can cause a UAF and a double free, which may lead to
RCE (may also lead to an LPE in case the attacker already has local
privileges)."

Hence, when a queue initialization fails after the ahash requests are
allocated, it is guaranteed that the queue removal async work will be
called, hence leave the deallocation to the queue removal.

Also, be extra careful not to continue processing the socket, so set
queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.

	Cc: stable@vger.kernel.org
	Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
	Tested-by: Alon Zahavi <zahavi.alon@gmail.com>
	Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
	Reviewed-by: Christoph Hellwig <hch@lst.de>
	Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
	Signed-off-by: Keith Busch <kbusch@kernel.org>
(cherry picked from commit d920abd)
	Signed-off-by: Greg Rose <g.v.rose@ciq.com>
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@gvrose8192 gvrose8192 merged commit dc1b070 into fips-9-compliant/5.14.0-284.30.1 Dec 20, 2024
4 checks passed
@gvrose8192 gvrose8192 deleted the gvrose_fips-9-compliant_5.14.0-284.30.1 branch December 20, 2024 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants