Skip to content

Conversation

bmastbergen
Copy link
Collaborator

Commits

    wifi: cfg80211: fix u8 overflow in cfg80211_update_notlisted_nontrans()

    jira VULN-3805
    cve CVE-2022-41674
    commit-author Johannes Berg <johannes.berg@intel.com>
    commit aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
    KVM: x86: do not report a vCPU as preempted outside instruction boundaries

    jira VULN-3802
    cve CVE-2022-39189
    commit-author Paolo Bonzini <pbonzini@redhat.com>
    commit 6cd88243c7e03845a450795e134b488fc2afb736
    devlink: Fix use-after-free after a failed reload

    jira VULN-3798
    cve CVE-2022-3625
    commit-author Ido Schimmel <idosch@nvidia.com>
    commit 6b4db2e528f650c7fb712961aac36455468d5902
    posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()

    jira VULN-136688
    cve CVE-2025-38352
    commit-author Oleg Nesterov <oleg@redhat.com>
    commit f90fff1e152dedf52b932240ebbd670d83330eca
    upstream-diff Used 5.4 LT 78a4b8e3795b31dae58762bc091bb0f4f74a2200 version

Build Log

/home/brett/kernel-src-tree
Running make mrproper...
[TIMER]{MRPROPER}: 8s
x86_64 architecture detected, copying config
'configs/kernel-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5"
Making olddefconfig
--
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --olddefconfig Kconfig
#
# configuration written to .config
#
Starting Build
scripts/kconfig/conf  --syncconfig Kconfig
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
--
  LD [M]  sound/usb/usx2y/snd-usb-usx2y.ko
  LD [M]  sound/virtio/virtio_snd.ko
  LD [M]  sound/x86/snd-hdmi-lpe-audio.ko
  LD [M]  sound/xen/snd_xen_front.ko
  LD [M]  virt/lib/irqbypass.ko
[TIMER]{BUILD}: 1234s
Making Modules
  INSTALL arch/x86/crypto/blowfish-x86_64.ko
  INSTALL arch/x86/crypto/camellia-aesni-avx2.ko
  INSTALL arch/x86/crypto/camellia-aesni-avx-x86_64.ko
  INSTALL arch/x86/crypto/camellia-x86_64.ko
--
  INSTALL sound/virtio/virtio_snd.ko
  INSTALL sound/x86/snd-hdmi-lpe-audio.ko
  INSTALL virt/lib/irqbypass.ko
  INSTALL sound/xen/snd_xen_front.ko
  DEPMOD  4.18.0-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5+
[TIMER]{MODULES}: 13s
Making Install
sh ./arch/x86/boot/install.sh 4.18.0-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5+ arch/x86/boot/bzImage \
	System.map "/boot"
[TIMER]{INSTALL}: 101s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-4.18.0-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5+ and Index to 0
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 8s
[TIMER]{BUILD}: 1234s
[TIMER]{MODULES}: 13s
[TIMER]{INSTALL}: 101s
[TIMER]{TOTAL} 1372s
Rebooting in 10 seconds

Testing

selftest-4.18.0-372.32.1.el8_6.86ciq_lts.14.1.x86_64.log

selftest-4.18.0-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5+.log

brett@lycia ~/ciq/many-86-vulns-9-9-25
 % grep ^ok selftest-4.18.0-372.32.1.el8_6.86ciq_lts.14.1.x86_64.log | wc -l
215
brett@lycia ~/ciq/many-86-vulns-9-9-25
 % grep ^ok selftest-4.18.0-bmastbergen_ciqlts8_6_many-vulns-9-9-25-5ebf8c3e84e5+.log | wc -l
215

…x_cpu_timer_del()

jira VULN-136688
cve CVE-2025-38352
commit-author Oleg Nesterov <oleg@redhat.com>
commit f90fff1
upstream-diff Used 5.4 LT 78a4b8e3795b31dae58762bc091bb0f4f74a2200 version

If an exiting non-autoreaping task has already passed exit_notify() and
calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent
or debugger right after unlock_task_sighand().

If a concurrent posix_cpu_timer_del() runs at that moment, it won't be
able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or
lock_task_sighand() will fail.

Add the tsk->exit_state check into run_posix_cpu_timers() to fix this.

This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because
exit_task_work() is called before exit_notify(). But the check still
makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail
anyway in this case.

	Cc: stable@vger.kernel.org
	Reported-by: Benoît Sevens <bsevens@google.com>
Fixes: 0bdd2ed ("sched: run_posix_cpu_timers: Don't check ->exit_state, use lock_task_sighand()")
	Signed-off-by: Oleg Nesterov <oleg@redhat.com>
	Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f90fff1)
	Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
jira VULN-3798
cve CVE-2022-3625
commit-author Ido Schimmel <idosch@nvidia.com>
commit 6b4db2e

After a failed devlink reload, devlink parameters are still registered,
which means user space can set and get their values. In the case of the
mlxsw "acl_region_rehash_interval" parameter, these operations will
trigger a use-after-free [1].

Fix this by rejecting set and get operations while in the failed state.
Return the "-EOPNOTSUPP" error code which does not abort the parameters
dump, but instead causes it to skip over the problematic parameter.

Another possible fix is to perform these checks in the mlxsw parameter
callbacks, but other drivers might be affected by the same problem and I
am not aware of scenarios where these stricter checks will cause a
regression.

[1]
mlxsw_spectrum3 0000:00:10.0: Port 125: Failed to register netdev
mlxsw_spectrum3 0000:00:10.0: Failed to create ports

==================================================================
BUG: KASAN: use-after-free in mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904
Read of size 4 at addr ffff8880099dcfd8 by task kworker/u4:4/777

CPU: 1 PID: 777 Comm: kworker/u4:4 Not tainted 5.19.0-rc7-custom-126601-gfe26f28c586d #1
Hardware name: QEMU MSN4700, BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: netns cleanup_net
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x92/0xbd lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:313 [inline]
 print_report.cold+0x5e/0x5cf mm/kasan/report.c:429
 kasan_report+0xb9/0xf0 mm/kasan/report.c:491
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report_generic.c:306
 mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904
 mlxsw_sp_acl_region_rehash_intrvl_get+0x49/0x60 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c:1106
 mlxsw_sp_params_acl_region_rehash_intrvl_get+0x33/0x80 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3854
 devlink_param_get net/core/devlink.c:4981 [inline]
 devlink_nl_param_fill+0x238/0x12d0 net/core/devlink.c:5089
 devlink_param_notify+0xe5/0x230 net/core/devlink.c:5168
 devlink_ns_change_notify net/core/devlink.c:4417 [inline]
 devlink_ns_change_notify net/core/devlink.c:4396 [inline]
 devlink_reload+0x15f/0x700 net/core/devlink.c:4507
 devlink_pernet_pre_exit+0x112/0x1d0 net/core/devlink.c:12272
 ops_pre_exit_list net/core/net_namespace.c:152 [inline]
 cleanup_net+0x494/0xc00 net/core/net_namespace.c:582
 process_one_work+0x9fc/0x1710 kernel/workqueue.c:2289
 worker_thread+0x675/0x10b0 kernel/workqueue.c:2436
 kthread+0x30c/0x3d0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 </TASK>

The buggy address belongs to the physical page:
page:ffffea0000267700 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99dc
flags: 0x100000000000000(node=0|zone=1)
raw: 0100000000000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8880099dce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8880099dcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff8880099dcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                    ^
 ffff8880099dd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8880099dd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================

Fixes: 98bbf70 ("mlxsw: spectrum: add "acl_region_rehash_interval" devlink param")
	Signed-off-by: Ido Schimmel <idosch@nvidia.com>
	Reviewed-by: Jiri Pirko <jiri@nvidia.com>
	Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6b4db2e)
	Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
…aries

jira VULN-3802
cve CVE-2022-39189
commit-author Paolo Bonzini <pbonzini@redhat.com>
commit 6cd8824

If a vCPU is outside guest mode and is scheduled out, it might be in the
process of making a memory access.  A problem occurs if another vCPU uses
the PV TLB flush feature during the period when the vCPU is scheduled
out, and a virtual address has already been translated but has not yet
been accessed, because this is equivalent to using a stale TLB entry.

To avoid this, only report a vCPU as preempted if sure that the guest
is at an instruction boundary.  A rescheduling request will be delivered
to the host physical CPU as an external interrupt, so for simplicity
consider any vmexit *not* instruction boundary except for external
interrupts.

It would in principle be okay to report the vCPU as preempted also
if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
vmentry/vmexit overhead unnecessarily, and optimistic spinning is
also unlikely to succeed.  However, leave it for later because right
now kvm_vcpu_check_block() is doing memory accesses.  Even
though the TLB flush issue only applies to virtual memory address,
it's very much preferrable to be conservative.

	Reported-by: Jann Horn <jannh@google.com>
	Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6cd8824)
	Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
jira VULN-3805
cve CVE-2022-41674
commit-author Johannes Berg <johannes.berg@intel.com>
commit aebe9f4

In the copy code of the elements, we do the following calculation
to reach the end of the MBSSID element:

	/* copy the IEs after MBSSID */
	cpy_len = mbssid[1] + 2;

This looks fine, however, cpy_len is a u8, the same as mbssid[1],
so the addition of two can overflow. In this case the subsequent
memcpy() will overflow the allocated buffer, since it copies 256
bytes too much due to the way the allocation and memcpy() sizes
are calculated.

Fix this by using size_t for the cpy_len variable.

This fixes CVE-2022-41674.

	Reported-by: Soenke Huster <shuster@seemoo.tu-darmstadt.de>
	Tested-by: Soenke Huster <shuster@seemoo.tu-darmstadt.de>
Fixes: 0b8fb82 ("cfg80211: Parsing of Multiple BSSID information in scanning")
	Reviewed-by: Kees Cook <keescook@chromium.org>
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit aebe9f4)
	Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
Copy link
Collaborator

@PlaidCat PlaidCat left a comment

Choose a reason for hiding this comment

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

:shipit:

Copy link
Collaborator

@kerneltoast kerneltoast left a comment

Choose a reason for hiding this comment

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

🚢

@bmastbergen bmastbergen merged commit 8afbd3c into ciqlts8_6 Sep 10, 2025
3 checks passed
@bmastbergen bmastbergen deleted the bmastbergen_ciqlts8_6/many-vulns-9-9-25 branch September 10, 2025 13:34
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.

3 participants