Skip to content

[LTS 8.8] CVE-2023-5633 #213

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[LTS 8.8] CVE-2023-5633 #213

wants to merge 1 commit into from

Conversation

pvts-mat
Copy link
Contributor

[LTS 8.8]
CVE-2023-5633
VULN-8160

Problem

https://www.cve.org/CVERecord?id=CVE-2023-5633

The reference count changes made as part of the CVE-2023-33951 and CVE-2023-33952 fixes exposed a use-after-free flaw in the way memory objects were handled when they were being used to store a surface. When running inside a VMware guest with 3D acceleration enabled, a local, unprivileged user could potentially use this flaw to escalate their privileges.

Applicability analysis

The contents of the files identified in #211 as the complete problem's domain are exactly the same in ciqlts8_8 as they are in ciqlts9_2

git --no-pager diff ciqlts8_8 ciqlts9_2 -- \
    drivers/gpu/drm/vmwgfx/Kconfig \
    drivers/gpu/drm/vmwgfx/Makefile \
    drivers/gpu/drm/vmwgfx/ttm_object.h \
    drivers/gpu/drm/vmwgfx/vmwgfx_bo.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_bo.h \
    drivers/gpu/drm/vmwgfx/vmwgfx_context.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.h \
    drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_fb.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_fence.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_gem.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_kms.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_kms.h \
    drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_prime.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_resource.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_shader.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_surface.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c \
    drivers/gpu/drm/vmwgfx/vmwgfx_va.c

which means that regardless of ciqlts8_8's vmwgfx driver's history the situation regarding CVE's applicability is the same as that of ciqlts9_2, which see.

The only difference can be found in the drivers/gpu/drm/vmwgfx/ttm_object.c file

diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c b/drivers/gpu/drm/vmwgfx/ttm_object.c
index bb350560f..26a55fef1 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -48,9 +48,12 @@
 #include <linux/spinlock.h>
 #include <linux/slab.h>
 #include <linux/atomic.h>
+#include <linux/module.h>
 #include "ttm_object.h"
 #include "vmwgfx_drv.h"
 
+MODULE_IMPORT_NS(DMA_BUF);
+
 /**
  * struct ttm_object_file
  *

which is related to the increased debugging information only, from the b9af383 commit

dma-buf: move dma-buf symbols into the DMA_BUF module namespace

Bugzilla: http://bugzilla.redhat.com/2030754
CVE: CVE-2021-44733

commit 16b0314aa746be6c84c0bc6eca9dde0dce2e99df
Author: Greg Kroah-Hartman <[email protected]>
Date:   Sun Oct 10 14:46:28 2021 +0200

    dma-buf: move dma-buf symbols into the DMA_BUF module namespace

    In order to better track where in the kernel the dma-buf code is used,
    put the symbols in the namespace DMA_BUF and modify all users of the
    symbols to properly import the namespace to not break the build at the
    same time.

    Now the output of modinfo shows the use of these symbols, making it
    easier to watch for users over time:

@pvts-mat pvts-mat changed the title Phony commit for PR discussion [LTS 8.8] CVE-2023-5633 Apr 14, 2025
@kerneltoast
Copy link
Collaborator

I completed maybe 90% of the backport for this back in my first week: https://github.com/ctrliq/kernel-src-tree/commits/%7Bsultan%7D_VULN-8160_ciqlts8_8/

@PlaidCat
Copy link
Collaborator

LTS has been deprecated we're going to cancel this one.

@PlaidCat PlaidCat closed this Jul 28, 2025
bmastbergen added a commit that referenced this pull request Sep 19, 2025
@bmastbergen
bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
226b67b 
jira VULN-66054
cve CVE-2022-49840
commit-author Baisong Zhong <[email protected]>
commit d3fd203

We got a syzkaller problem because of aarch64 alignment fault
if KFENCE enabled. When the size from user bpf program is an odd
number, like 399, 407, etc, it will cause the struct skb_shared_info's
unaligned access. As seen below:

  BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032

  Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
   __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
   arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
   arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
   atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
   __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
   skb_clone+0xf4/0x214 net/core/skbuff.c:1481
   ____bpf_clone_redirect net/core/filter.c:2433 [inline]
   bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
   bpf_prog_d3839dd9068ceb51+0x80/0x330
   bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
   bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
   bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
   bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
   __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
   __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381

  kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512

  allocated by task 15074 on cpu 0 at 1342.585390s:
   kmalloc include/linux/slab.h:568 [inline]
   kzalloc include/linux/slab.h:675 [inline]
   bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
   bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
   bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
   __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
   __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
   __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381

To fix the problem, we adjust @SiZe so that (@SiZe + @hearoom) is a
multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
is aligned to a cache line.

Fixes: 1cf1cae ("bpf: introduce BPF_PROG_TEST_RUN command")
	Signed-off-by: Baisong Zhong <[email protected]>
	Signed-off-by: Daniel Borkmann <[email protected]>
	Cc: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit d3fd203)
	Signed-off-by: Brett Mastbergen <[email protected]>
bmastbergen added a commit that referenced this pull request Sep 24, 2025
@bmastbergen
bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
624338c 
jira VULN-66054
cve CVE-2022-49840
commit-author Baisong Zhong <[email protected]>
commit d3fd203

We got a syzkaller problem because of aarch64 alignment fault
if KFENCE enabled. When the size from user bpf program is an odd
number, like 399, 407, etc, it will cause the struct skb_shared_info's
unaligned access. As seen below:

  BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032

  Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
   __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
   arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
   arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
   atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
   __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
   skb_clone+0xf4/0x214 net/core/skbuff.c:1481
   ____bpf_clone_redirect net/core/filter.c:2433 [inline]
   bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
   bpf_prog_d3839dd9068ceb51+0x80/0x330
   bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
   bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
   bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
   bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
   __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
   __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381

  kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512

  allocated by task 15074 on cpu 0 at 1342.585390s:
   kmalloc include/linux/slab.h:568 [inline]
   kzalloc include/linux/slab.h:675 [inline]
   bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
   bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
   bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
   __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
   __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
   __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381

To fix the problem, we adjust @SiZe so that (@SiZe + @hearoom) is a
multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
is aligned to a cache line.

Fixes: 1cf1cae ("bpf: introduce BPF_PROG_TEST_RUN command")
	Signed-off-by: Baisong Zhong <[email protected]>
	Signed-off-by: Daniel Borkmann <[email protected]>
	Cc: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit d3fd203)
	Signed-off-by: Brett Mastbergen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@pvts-mat @kerneltoast @PlaidCat