Skip to content

Conversation

PlaidCat
Copy link
Collaborator

FIPS touching changes

None

[jmaple@devbox kernel-src-tree]$ for git_path in arch/x86/crypto/ crypto/asymmetric_keys/ crypto/ drivers/crypto/ drivers/char/random.c include/crypto; do echo "== $git_path =="; git log --oneline --name-only origin/fips-8-compliant/4.18.0-553.16.1..HEAD $git_path; done
== arch/x86/crypto/ ==
== crypto/asymmetric_keys/ ==
== crypto/ ==
== drivers/crypto/ ==
== drivers/char/random.c ==
== include/crypto ==

Commits

    net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class

    jira VULN-89289
    jira VULN-89290
    cve-bf CVE-2025-38477
    commit-author Xiang Mei <[email protected]>
    commit cf074eca0065bc5142e6004ae236bb35a2687fdf
    net/sched: sch_qfq: Fix race condition on qfq_aggregate

    jira VULN-89290
    jira VULN-89289
    cve CVE-2025-38477
    commit-author Xiang Mei <[email protected]>
    commit 5e28d5a3f774f118896aec17a3a20a9c5c9dfc64
    tipc: Fix use-after-free in tipc_conn_close().

    jira VULN-80316
    jira VULN-80315
    cve CVE-2025-38464
    commit-author Kuniyuki Iwashima <[email protected]>
    commit 667eeab4999e981c96b447a4df5f20bdf5c26f13
    idpf: convert control queue mutex to a spinlock

    jira VULN-136697
    jira VULN-136696
    cve CVE-2025-38392
    commit-author Ahmed Zaki <[email protected]>
    commit b2beb5bb2cd90d7939e470ed4da468683f41baa3
    scsi: lpfc: Use memcpy() for BIOS version

    jira VULN-72456
    jira VULN-72455
    cve CVE-2025-38332
    commit-author Daniel Wagner <[email protected]>
    commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d

KBuild

[jmaple@devbox code]$ egrep -B 5 -A 5 "\[TIMER\]|^Starting Build" $(ls -t kbuild* | head -n1)
/mnt/code/kernel-src-tree-build
Running make mrproper...
[TIMER]{MRPROPER}: 5s
x86_64 architecture detected, copying config
'configs/kernel-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-9a06"
Making olddefconfig
--
  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
--
  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}: 1958s
Making Modules
  INSTALL arch/x86/crypto/blowfish-x86_64.ko
  INSTALL arch/x86/crypto/camellia-aesni-avx-x86_64.ko
  INSTALL arch/x86/crypto/camellia-aesni-avx2.ko
  INSTALL arch/x86/crypto/camellia-x86_64.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-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-9a06+
[TIMER]{MODULES}: 15s
Making Install
sh ./arch/x86/boot/install.sh 4.18.0-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-9a06+ arch/x86/boot/bzImage \
        System.map "/boot"
[TIMER]{INSTALL}: 21s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-4.18.0-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-9a06+ and Index to 0
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 5s
[TIMER]{BUILD}: 1958s
[TIMER]{MODULES}: 15s
[TIMER]{INSTALL}: 21s
[TIMER]{TOTAL} 2005s
Rebooting in 10 seconds

KSelfTest

[jmaple@devbox code]$ ls -rt kselftest.* | tail -n4 | while read line; do echo $line; grep '^ok ' $line | wc -l ; done
kselftest.4.18.0-553.16.1.el8_10.ciqfips.0.13.1.x86_64.log
201
kselftest.4.18.0-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-0bc2+.log
204
kselftest.4.18.0-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-d70e+.log
204
kselftest.4.18.0-jmaple_batch_12_fips-8-compliant_4.18.0-553.16.1-9a06+.log
204

jira VULN-72456
jira VULN-72455
cve CVE-2025-38332
commit-author Daniel Wagner <[email protected]>
commit ae82eaf

The strlcat() with FORTIFY support is triggering a panic because it
thinks the target buffer will overflow although the correct target
buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use
memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfc_printf_log() which expects a
properly terminated string.

	Signed-off-by: Daniel Wagner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Reviewed-by: Justin Tee <[email protected]>
	Signed-off-by: Martin K. Petersen <[email protected]>
(cherry picked from commit ae82eaf)
	Signed-off-by: Jonathan Maple <[email protected]>
jira VULN-136697
jira VULN-136696
cve CVE-2025-38392
commit-author Ahmed Zaki <[email protected]>
commit b2beb5b

With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated
on module load:

[  324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578
[  324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager
[  324.701689] preempt_count: 201, expected: 0
[  324.701693] RCU nest depth: 0, expected: 0
[  324.701697] 2 locks held by NetworkManager/1582:
[  324.701702]  #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0
[  324.701730]  #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870
[  324.701749] Preemption disabled at:
[  324.701752] [<ffffffff9cd23b9d>] __dev_open+0x3dd/0x870
[  324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)
[  324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022
[  324.701774] Call Trace:
[  324.701777]  <TASK>
[  324.701779]  dump_stack_lvl+0x5d/0x80
[  324.701788]  ? __dev_open+0x3dd/0x870
[  324.701793]  __might_resched.cold+0x1ef/0x23d
<..>
[  324.701818]  __mutex_lock+0x113/0x1b80
<..>
[  324.701917]  idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]
[  324.701935]  ? kasan_save_track+0x14/0x30
[  324.701941]  idpf_mb_clean+0x143/0x380 [idpf]
<..>
[  324.701991]  idpf_send_mb_msg+0x111/0x720 [idpf]
[  324.702009]  idpf_vc_xn_exec+0x4cc/0x990 [idpf]
[  324.702021]  ? rcu_is_watching+0x12/0xc0
[  324.702035]  idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]
<..>
[  324.702122]  __hw_addr_sync_dev+0x1cf/0x300
[  324.702126]  ? find_held_lock+0x32/0x90
[  324.702134]  idpf_set_rx_mode+0x317/0x390 [idpf]
[  324.702152]  __dev_open+0x3f8/0x870
[  324.702159]  ? __pfx___dev_open+0x10/0x10
[  324.702174]  __dev_change_flags+0x443/0x650
<..>
[  324.702208]  netif_change_flags+0x80/0x160
[  324.702218]  do_setlink.isra.0+0x16a0/0x3960
<..>
[  324.702349]  rtnl_newlink+0x12fd/0x21e0

The sequence is as follows:
	rtnl_newlink()->
	__dev_change_flags()->
	__dev_open()->
	dev_set_rx_mode() - >  # disables BH and grabs "dev->addr_list_lock"
	idpf_set_rx_mode() ->  # proceed only if VIRTCHNL2_CAP_MACFILTER is ON
	__dev_uc_sync() ->
	idpf_add_mac_filter ->
	idpf_add_del_mac_filters ->
	idpf_send_mb_msg() ->
	idpf_mb_clean() ->
	idpf_ctlq_clean_sq()   # mutex_lock(cq_lock)

Fix by converting cq_lock to a spinlock. All operations under the new
lock are safe except freeing the DMA memory, which may use vunmap(). Fix
by requesting a contiguous physical memory for the DMA mapping.

Fixes: a251eee ("idpf: add SRIOV support and other ndo_ops")
	Reviewed-by: Aleksandr Loktionov <[email protected]>
	Signed-off-by: Ahmed Zaki <[email protected]>
	Reviewed-by: Simon Horman <[email protected]>
	Tested-by: Samuel Salin <[email protected]>
	Signed-off-by: Tony Nguyen <[email protected]>
(cherry picked from commit b2beb5b)
	Signed-off-by: Jonathan Maple <[email protected]>
jira VULN-80316
jira VULN-80315
cve CVE-2025-38464
commit-author Kuniyuki Iwashima <[email protected]>
commit 667eeab

syzbot reported a null-ptr-deref in tipc_conn_close() during netns
dismantle. [0]

tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls
tipc_conn_close() for each tipc_conn.

The problem is that tipc_conn_close() is called after releasing the
IDR lock.

At the same time, there might be tipc_conn_recv_work() running and it
could call tipc_conn_close() for the same tipc_conn and release its
last ->kref.

Once we release the IDR lock in tipc_topsrv_stop(), there is no
guarantee that the tipc_conn is alive.

Let's hold the ref before releasing the lock and put the ref after
tipc_conn_close() in tipc_topsrv_stop().

[0]:
BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354
 kasan_report mm/kasan/report.c:412 [inline]
 __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]
 tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722
 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153
 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Allocated by task 23:
 kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625
 kmalloc include/linux/slab.h:515 [inline]
 kzalloc include/linux/slab.h:709 [inline]
 tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192
 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Freed by task 23:
 __cache_free mm/slab.c:3503 [inline]
 kfree+0xcc/0x210 mm/slab.c:3822
 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]
 kref_put include/linux/kref.h:70 [inline]
 conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff888099305a00
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 8 bytes inside of
 512-byte region [ffff888099305a00, ffff888099305c00)
The buggy address belongs to the page:
page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0
flags: 0xfff00000000100(slab)
raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940
raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Fixes: c5fa7b3 ("tipc: introduce new TIPC server infrastructure")
	Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=27169a847a70550d17be
	Signed-off-by: Kuniyuki Iwashima <[email protected]>
	Reviewed-by: Tung Nguyen <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 667eeab)
	Signed-off-by: Jonathan Maple <[email protected]>
jira VULN-89290
jira VULN-89289
cve CVE-2025-38477
commit-author Xiang Mei <[email protected]>
commit 5e28d5a

A race condition can occur when 'agg' is modified in qfq_change_agg
(called during qfq_enqueue) while other threads access it
concurrently. For example, qfq_dump_class may trigger a NULL
dereference, and qfq_delete_class may cause a use-after-free.

This patch addresses the issue by:

1. Moved qfq_destroy_class into the critical section.

2. Added sch_tree_lock protection to qfq_dump_class and
qfq_dump_class_stats.

Fixes: 462dbc9 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
	Signed-off-by: Xiang Mei <[email protected]>
	Reviewed-by: Cong Wang <[email protected]>
	Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit 5e28d5a)
	Signed-off-by: Jonathan Maple <[email protected]>
… qfq_delete_class

jira VULN-89289
jira VULN-89290
cve-bf CVE-2025-38477
commit-author Xiang Mei <[email protected]>
commit cf074ec

might_sleep could be trigger in the atomic context in qfq_delete_class.

qfq_destroy_class was moved into atomic context locked
by sch_tree_lock to avoid a race condition bug on
qfq_aggregate. However, might_sleep could be triggered by
qfq_destroy_class, which introduced sleeping in atomic context (path:
qfq_destroy_class->qdisc_put->__qdisc_destroy->lockdep_unregister_key
->might_sleep).

Considering the race is on the qfq_aggregate objects, keeping
qfq_rm_from_agg in the lock but moving the left part out can solve
this issue.

Fixes: 5e28d5a ("net/sched: sch_qfq: Fix race condition on qfq_aggregate")
	Reported-by: Dan Carpenter <[email protected]>
	Signed-off-by: Xiang Mei <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Reviewed-by: Cong Wang <[email protected]>
	Reviewed-by: Dan Carpenter <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Paolo Abeni <[email protected]>

(cherry picked from commit cf074ec)
	Signed-off-by: Jonathan Maple <[email protected]>
Copy link

🔍 Upstream Linux Kernel Commit Check

  • ⚠️ PR commit c1bf8405c850 (net/sched: sch_qfq: Fix race condition on qfq_aggregate) references upstream commit
    5e28d5a3f774 which has been referenced by a Fixes: tag in the upstream
    Linux kernel:
    cf074eca0065 net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class (Xiang Mei)

This is an automated message from the kernel commit checker workflow.

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.

🥌

@PlaidCat PlaidCat merged commit 9a068aa into fips-8-compliant/4.18.0-553.16.1 Sep 19, 2025
4 checks passed
@PlaidCat PlaidCat deleted the {jmaple}_batch_12_fips-8-compliant/4.18.0-553.16.1 branch September 19, 2025 18:24
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