[LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 #114

gvrose8192 · 2025-02-12T00:16:13Z

Also adds the most up to date kernel workflows.

Since we need to make sure external contributors code actually compiles prior to merging. To get access to the forked repos merge request we need to switch over our push to pull_request. In addition we're fixing up some Naming Conventions, adding aarch64 to this branch and fixing the naming so that we can quickly identify if the CI is for x86_64 or aarch64. Also disable the process-pull-request until the `utf-8` situation is resolved.

gvrose8192 · 2025-02-12T00:18:11Z

fips-810-compliant-build.log
Uploading fips-810-compliant-build.log…

gvrose8192 · 2025-02-12T00:18:55Z

Using the new auto build and kernel self test automation for the logs.

bmastbergen · 2025-02-12T14:28:35Z

I think the ticket in the commit is wrong. Shouldn't it be VULN-9672 ?

…parse_format jira VULN-9672 cve CVE-2024-53104 commit-author Benoit Sevens <bsevens@google.com> commit ecf2b43 This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. Fixes: c0efd23 ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Benoit Sevens <bsevens@google.com> Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> (cherry picked from commit ecf2b43) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

gvrose8192 · 2025-02-12T19:13:44Z

I think the ticket in the commit is wrong. Shouldn't it be VULN-9672 ?

Yep, fixed. Thanks!

gvrose8192 · 2025-02-12T19:51:00Z

fips-810-compliant.log
This is the commands log.
Captured via executing 'script fips-810-compliant.log' and then running the automation scripts to configure and run build / test scripts on the runner.

PlaidCat · 2025-02-12T20:02:56Z

fips-810-compliant-build.log
Uploading fips-810-compliant-build.log…

  INSTALL virt/lib/irqbypass.ko
  DEPMOD  4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+
[TIMER]{MODULES}: 89s
Making Install
sh ./arch/x86/boot/install.sh 4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+ arch/x86/boot/bzImage \
	System.map "/boot"
[TIMER]{INSTALL}: 31s
Checking kABI
Checking kABI
Error: kABI check failed
sleep 30 seconds after build command has finished

fips-810-compliant.log
This is the commands log.

These tests look like the failed or got corrupted?

[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-4.18.0-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-gvrose_fips-8-complaint_4.18.0-553.16.1"
Making olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --olddefconfig Kconfig
#
# configuration written to .config
#
Starting Build
scripts/kconfig/conf  --syncconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  UPD     include/config/kernel.release
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
�[7mESC�[27m[7mfips-810-compliant-build.log�[7mESC�[27m[27m�[7mESC�[27m[K�[7m^MESC�[27m[K �[7mESC�[27m[K�[1mE�[0mSC�[7mESC�[27m[K�[1mO�[0m�[7mESC�[27m[K�[1mF�[0m�[7m^MESC�[27m[K...skipping...
# [OK]  mremap to 0x7fffffffffff000 failed
# [RUN] Trying a SYSCALL that falls through to 0xffffffffffff000
# [OK]  mremap to 0xfffffffffffe000 failed
# [RUN] Trying a SYSCALL that falls through to 0x1000000000000000
# [OK]  mremap to 0xffffffffffff000 failed

ok 17 selftests: x86: corrupt_xstate_header_64
# timeout set to 45
# selftests: x86: amx_64
# amx_64: [FAIL]        xstate cpuid: invalid tile data size/offset: 0/0: Success
not ok 18 selftests: x86: amx_64 # exit=1
make[1]: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests/x86'
make: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests'
make: Entering directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests'
make --no-builtin-rules ARCH=x86 -C ../../.. headers_install
make[1]: Entering directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1'
make[1]: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1'
:�[K
�[K�
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K

gvrose8192 · 2025-02-12T20:40:22Z

fips-810-compliant-build.log
Uploading fips-810-compliant-build.log…

  INSTALL virt/lib/irqbypass.ko
  DEPMOD  4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+
[TIMER]{MODULES}: 89s
Making Install
sh ./arch/x86/boot/install.sh 4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+ arch/x86/boot/bzImage \
	System.map "/boot"
[TIMER]{INSTALL}: 31s
Checking kABI
Checking kABI
Error: kABI check failed
sleep 30 seconds after build command has finished

fips-810-compliant.log
This is the commands log.

These tests look like the failed or got corrupted?

[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-4.18.0-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-gvrose_fips-8-complaint_4.18.0-553.16.1"
Making olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --olddefconfig Kconfig
#
# configuration written to .config
#
Starting Build
scripts/kconfig/conf  --syncconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  UPD     include/config/kernel.release
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
�[7mESC�[27m[7mfips-810-compliant-build.log�[7mESC�[27m[27m�[7mESC�[27m[K�[7m^MESC�[27m[K �[7mESC�[27m[K�[1mE�[0mSC�[7mESC�[27m[K�[1mO�[0m�[7mESC�[27m[K�[1mF�[0m�[7m^MESC�[27m[K...skipping...
# [OK]  mremap to 0x7fffffffffff000 failed
# [RUN] Trying a SYSCALL that falls through to 0xffffffffffff000
# [OK]  mremap to 0xfffffffffffe000 failed
# [RUN] Trying a SYSCALL that falls through to 0x1000000000000000
# [OK]  mremap to 0xffffffffffff000 failed

ok 17 selftests: x86: corrupt_xstate_header_64
# timeout set to 45
# selftests: x86: amx_64
# amx_64: [FAIL]        xstate cpuid: invalid tile data size/offset: 0/0: Success
not ok 18 selftests: x86: amx_64 # exit=1
make[1]: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests/x86'
make: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests'
make: Entering directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1/tools/testing/selftests'
make --no-builtin-rules ARCH=x86 -C ../../.. headers_install
make[1]: Entering directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1'
make[1]: Leaving directory '/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1'
:�[K
�[K�
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K
�[K
�[K:�[K

Let me look at that some more - seems to be an error in checking out the correct kernel-dist-git branch from the correct kernel-dist-git repo, because we have 3 of them for what I'm sure is a very good reason.

Thanks for helping me shake this out.

gvrose8192 · 2025-02-12T23:14:54Z

The correct dist-git branch for FIPS 8.10 Compliant is supposed to be el810-fips-compliant-8? The correct branch for kernel-dist-git is checked out.
`[gvrose8192@auto-kernel-test-fips810 kernel-dist-git]$ git branch

el810-fips-compliant-8
lts86-8
`
Let me try debugging it locally, none of my other kernel automation tests are experiencing this issue.

gvrose8192 · 2025-02-14T23:30:31Z

The correct dist-git branch for FIPS 8.10 Compliant is supposed to be el810-fips-compliant-8? The correct branch for kernel-dist-git is checked out. `[gvrose8192@auto-kernel-test-fips810 kernel-dist-git]$ git branch

el810-fips-compliant-8
lts86-8
`
Let me try debugging it locally, none of my other kernel automation tests are experiencing this issue.

The automation issue with branch names that need normalization is fixed and a second pass has run.
Builds and Loads

our branch is up to date with 'origin/main'.
branch 'gvrose_fips-8-complaint/4.18.0-553.16.1' set up to track 'origin/gvrose_fips-8-complaint/4.18.0-553.16.1'.
Already up to date.
/home/gvrose8192/prj/kernel-build-gvrose_fips-8-complaint/4.18.0-553.16.1
no .config file found, moving on
[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-4.18.0-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-gvrose_fips-8-complaint_4.18.0-553.16.1"
Making olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --olddefconfig Kconfig
#
# configuration written to .config
#
Starting Build
scripts/kconfig/conf  --syncconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h

[SNIP]

  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
  INSTALL sound/virtio/virtio_snd.ko
  INSTALL sound/x86/snd-hdmi-lpe-audio.ko
  INSTALL sound/xen/snd_xen_front.ko
  INSTALL virt/lib/irqbypass.ko
  DEPMOD  4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+
[TIMER]{MODULES}: 83s
Making Install
sh ./arch/x86/boot/install.sh 4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+ arch/x86/boot/bzImage \
        System.map "/boot"
[TIMER]{INSTALL}: 35s
Checking kABI
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+ and Index to 0
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 0s
[TIMER]{BUILD}: 5177s
[TIMER]{MODULES}: 83s
[TIMER]{INSTALL}: 35s
[TIMER]{TOTAL} 5317s
Rebooting in 10 seconds

[gvrose8192@auto-kernel-test-fips810 ~]$ uname -a
Linux auto-kernel-test-fips810 4.18.0-gvrose_fips-8-complaint_4.18.0-553.16.1+ #1 SMP Fri Feb 14 20:59:34 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Commands and Build logs
lts-8_10-commands-pass3.log
lts-8_10-build-pass3.log

There's no reason to think this patch would cause any issues.

gvrose8192 · 2025-02-14T23:32:59Z

Brett and Maple, please give this another pass. I've solved the issues with the kernel automation tools, normalization of branch names and a few other goodies.

Thanks!

bmastbergen

🥌

gvrose8192 · 2025-02-18T21:18:53Z

Jeremy asked for changes to the branch names for this PR - will get that done and repost. This one is closed due to the branch name changes.

After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). Fixes: ba8c3d6 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/ff7849e268562456274213c0476e09481a48f489.1742833382.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>

[ Upstream commit 378677e ] After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). Fixes: ba8c3d6 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/ff7849e268562456274213c0476e09481a48f489.1742833382.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

JIRA: https://issues.redhat.com/browse/RHEL-89169 CVE: CVE-2025-37794 commit 378677e Author: Remi Pommarel <repk@triplefau.lt> Date: Mon Mar 24 17:28:21 2025 +0100 wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). Fixes: ba8c3d6 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/ff7849e268562456274213c0476e09481a48f489.1742833382.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

gvrose8192 requested review from PlaidCat and bmastbergen February 12, 2025 00:19

gvrose8192 changed the title ~~[LTS 8.8 fips] fips 8 complaint/4.18.0 553.16.1~~ [LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 Feb 12, 2025

gvrose8192 force-pushed the gvrose_fips-8-complaint/4.18.0-553.16.1 branch from f7af8a5 to 45e71cc Compare February 12, 2025 19:12

bmastbergen approved these changes Feb 18, 2025

View reviewed changes

gvrose8192 closed this Feb 18, 2025

gvrose8192 deleted the gvrose_fips-8-complaint/4.18.0-553.16.1 branch February 18, 2025 21:13

PlaidCat mentioned this pull request Feb 18, 2025

[LTS 8.10 FIPS] CVE-2024-53104 kernel fips-8.10 #133

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 #114

[LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 #114

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

bmastbergen commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025 •

edited

Loading

Uh oh!

PlaidCat commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025 •

edited

Loading

Uh oh!

gvrose8192 commented Feb 14, 2025

Uh oh!

gvrose8192 commented Feb 14, 2025

Uh oh!

bmastbergen left a comment

Uh oh!

gvrose8192 commented Feb 18, 2025

Uh oh!

Uh oh!

[LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 #114

[LTS 8.10 fips] fips 8 complaint/4.18.0 553.16.1 #114

Uh oh!

Conversation

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

bmastbergen commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PlaidCat commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025

Uh oh!

gvrose8192 commented Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gvrose8192 commented Feb 14, 2025

Uh oh!

gvrose8192 commented Feb 14, 2025

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

gvrose8192 commented Feb 18, 2025

Uh oh!

Uh oh!

gvrose8192 commented Feb 12, 2025 •

edited

Loading

gvrose8192 commented Feb 12, 2025 •

edited

Loading