RHSA-2026:18134
Vulnerability from csaf_redhat - Published: 2026-05-19 09:04 - Updated: 2026-09-02 20:39In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke sk_msg_free. Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same warning will be reported in selftest. [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of sk_msg_free_partial we can do sk_msg_free here.
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-debug-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-debug-devel-matched-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-64k-devel-matched-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-matched-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-matched-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-matched-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debug-devel-matched-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-common-aarch64-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-common-ppc64le-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-common-s390x-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-debuginfo-common-x86_64-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-matched-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-matched-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-matched-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-devel-matched-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-doc-0:6.12.0-211.7.1.el10_2.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-zfcpdump-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-zfcpdump-devel-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:kernel-zfcpdump-devel-matched-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rtla-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rtla-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rtla-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rtla-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rv-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rv-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rv-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-10.2.GA:rv-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-0:6.12.0-211.7.1.el10_2.src | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debug-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-64k-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-abi-stablelists-0:6.12.0-211.7.1.el10_2.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-core-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-core-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-core-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-extra-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-extra-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debug-uki-virt-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-common-aarch64-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-common-ppc64le-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-common-s390x-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-debuginfo-common-x86_64-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-core-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-matched-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-matched-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-matched-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-modules-extra-matched-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-libs-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-libs-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-tools-libs-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-uki-virt-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-uki-virt-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-uki-virt-addons-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-uki-virt-addons-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-modules-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-modules-core-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:kernel-zfcpdump-modules-extra-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-common-aarch64-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-common-ppc64le-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-common-s390x-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-debuginfo-common-x86_64-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-libs-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-libs-devel-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-tools-libs-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:kernel-zfcpdump-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-debuginfo-common-x86_64-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debug-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-rt-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debuginfo-common-aarch64-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-debuginfo-common-x86_64-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debug-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-64k-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debug-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-devel-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-devel-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-core-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-core-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-extra-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-rt-modules-extra-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:kernel-tools-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:libperf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-10.2.GA:python3-perf-debuginfo-0:6.12.0-211.7.1.el10_2.x86_64 | — |
Vendor Fix
fix
|
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop Move the conditional loading of hardware DR6 with the guest's DR6 value out of the core .vcpu_run() loop to fix a bug where KVM can load hardware with a stale vcpu->arch.dr6. When the guest accesses a DR and host userspace isn't debugging the guest, KVM disables DR interception and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at will, e.g. so that a sequence of DR accesses to configure a breakpoint only generates one VM-Exit. For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest) and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop. But for DR6, the guest's value doesn't need to be loaded into hardware for KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually load the guest value, and so loading the guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done _inside_ the core run loop. Unfortunately, saving the guest values on VM-Exit is initiated by common x86, again outside of the core run loop. If the guest modifies DR6 (in hardware, when DR interception is disabled), and then the next VM-Exit is a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and clobber the guest's actual value. The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the window between hardware DR6 being modified (in guest context) and DR6 being read by guest software is orders of magnitude larger in a nested setup. E.g. in non-nested, the VMX preemption timer would need to fire precisely between #DB injection and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the window where hardware DR6 is "dirty" extends all the way from L1 writing DR6 to VMRESUME (in L1). L1's view: ========== <L1 disables DR interception> CPU 0/KVM-7289 [023] d.... 2925.640961: kvm_entry: vcpu 0 A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <hack>: Set DRs, DR6 = 0xffff0ff1 B: CPU 0/KVM-7289 [023] d.... 2925.640967: kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT intr_info 0x800000ec D: L1 reads DR6, arch.dr6 = 0 CPU 0/KVM-7289 [023] d.... 2925.640969: <hack>: Sync DRs, DR6 = 0xffff0ff0 CPU 0/KVM-7289 [023] d.... 2925.640976: kvm_entry: vcpu 0 L2 reads DR6, L1 disables DR interception CPU 0/KVM-7289 [023] d.... 2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216 CPU 0/KVM-7289 [023] d.... 2925.640983: kvm_entry: vcpu 0 CPU 0/KVM-7289 [023] d.... 2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0 L2 detects failure CPU 0/KVM-7289 [023] d.... 2925.640987: kvm_exit: vcpu 0 reason HLT L1 reads DR6 (confirms failure) CPU 0/KVM-7289 [023] d.... 2925.640990: <hack>: Sync DRs, DR6 = 0xffff0ff0 L0's view: ========== L2 reads DR6, arch.dr6 = 0 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 L2 => L1 nested VM-Exit CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_exit: vcpu 23 reason VMREAD CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410. ---truncated---
In the Linux kernel, the following vulnerability has been resolved: block: fix resource leak in blk_register_queue() error path When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources. Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.
CWE-459 - Incomplete CleanupIn the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.
In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.
CWE-772 - Missing Release of Resource after Effective LifetimeIn the Linux kernel, the following vulnerability has been resolved: bpf: fix ktls panic with sockmap [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data(). If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' The changes in this commit are based on the following considerations: 1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic. 2. We can not calculate the correct number of bytes to revert msg_iter. Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement. However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' So it's ok to just return 'copied' without error when a "cork" situation occurs.
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.
CWE-414 - Missing Lock CheckIn the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not trigger WARN_ON() due to a commit_overrun When reading a memory mapped buffer the reader page is just swapped out with the last page written in the write buffer. If the reader page is the same as the commit buffer (the buffer that is currently being written to) it was assumed that it should never have missed events. If it does, it triggers a WARN_ON_ONCE(). But there just happens to be one scenario where this can legitimately happen. That is on a commit_overrun. A commit overrun is when an interrupt preempts an event being written to the buffer and then the interrupt adds so many new events that it fills and wraps the buffer back to the commit. Any new events would then be dropped and be reported as "missed_events". In this case, the next page to read is the commit buffer and after the swap of the reader page, the reader page will be the commit buffer, but this time there will be missed events and this triggers the following warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780 Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50 RSP: 0018:ffff888121787dc0 EFLAGS: 00010002 RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49 RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982 R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00 R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008 FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0 Call Trace: <TASK> ? __pfx_ring_buffer_map_get_reader+0x10/0x10 tracing_buffers_ioctl+0x283/0x370 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f95c8de48db Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006 RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90 </TASK> irq event stamp: 5080 hardirqs last enabled at (5079): [<ffffffff83e0adb0>] _raw_spin_unlock_irqrestore+0x50/0x70 hardirqs last disabled at (5080): [<ffffffff83e0aa83>] _raw_spin_lock_irqsave+0x63/0x70 softirqs last enabled at (4182): [<ffffffff81516122>] handle_softirqs+0x552/0x710 softirqs last disabled at (4159): [<ffffffff815163f7>] __irq_exit_rcu+0x107/0x210 ---[ end trace 0000000000000000 ]--- The above was triggered by running on a kernel with both lockdep and KASAN as well as kmemleak enabled and executing the following command: # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50 With perf interjecting a lot of interrupts and trace-cmd enabling all events as well as function tracing, with lockdep, KASAN and kmemleak enabled, it could cause an interrupt preempting an event being written to add enough event ---truncated---
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling.
In the Linux kernel, the following vulnerability has been resolved: bpf: Do not include stack ptr register in precision backtracking bookkeeping Yi Lai reported an issue ([1]) where the following warning appears in kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] <TASK> [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci ---truncated---
CWE-824 - Access of Uninitialized PointerIn the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak.
CWE-772 - Missing Release of Resource after Effective LifetimeIn the Linux kernel, the following vulnerability has been resolved: ftrace: Fix UAF when lookup kallsym after ftrace disabled The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the "mod" no longer exists and triggers a UAF bug.
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak of bio integrity If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity in bio.
CWE-772 - Missing Release of Resource after Effective LifetimeIn the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto() syzbot found a potential access to uninit-value in nf_flow_pppoe_proto() Blamed commit forgot the Ethernet header. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]
In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---
In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.
In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.
A flaw was found in the Linux kernel PCI/AER (Advanced Error Reporting) subsystem. When platform firmware reports error information via the ACPI APEI GHES mechanism for a device that does not advertise an AER capability, dev->aer_info remains NULL. The function aer_ratelimit() does not check for this condition, leading to a NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved: dm: fix NULL pointer dereference in __dm_suspend() There is a race condition between dm device suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes: BUG: kernel NULL pointer dereference, address: 0000000000000054 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50 Call Trace: <TASK> blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0 The issue can be triggered as below: T1 T2 dm_suspend table_load __dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1) dm_stop_queue / dm_wait_for_completion => q->tag_set NULL pointer! (2) => q->tag_set = set; (3) Fix this by checking if a valid table (map) exists before performing request-based suspend and waiting for target I/O. When map is NULL, skip these table-dependent suspend steps. Even when map is NULL, no I/O can reach any target because there is no table loaded; I/O submitted in this state will fail early in the DM layer. Skipping the table-dependent suspend logic in this case is safe and avoids NULL pointer dereferences.
In the Linux kernel, the following vulnerability has been resolved: Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND" I've found that pynfs COMP6 now leaves the connection or lease in a strange state, which causes CLOSE9 to hang indefinitely. I've dug into it a little, but I haven't been able to root-cause it yet. However, I bisected to commit 48aab1606fa8 ("NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"). Tianshuo Han also reports a potential vulnerability when decoding an NFSv4 COMPOUND. An attacker can place an arbitrarily large op count in the COMPOUND header, which results in: [ 51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 when NFSD attempts to allocate the COMPOUND op array. Let's restore the operation-per-COMPOUND limit, but increased to 200 for now.
A flaw was found in the Linux kernel's Multipath TCP (MPTCP) implementation. A race condition in the `mptcp_pm_del_add_timer()` function allows for a use-after-free vulnerability. This can be exploited by a local attacker to cause a denial of service (DoS), potentially leading to privilege escalation or arbitrary code execution.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential cfid UAF in smb2_query_info_compound When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80
A flaw was found in the Linux kernel. A local user could exploit a vulnerability where freezing the request queue within certain sysfs store callbacks can lead to a deadlock. This issue may occur when combined with the device-mapper multipath (dm-multipath) driver and the `queue_if_no_path` option, or when sysfs attributes are set synchronously. Successful exploitation could result in a Denial of Service (DoS) by making the system unresponsive.
In the Linux kernel, the following vulnerability has been resolved: lib/buildid: use __kernel_read() for sleepable context Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio". For the sleepable context, convert freader to use __kernel_read() instead of direct page cache access via read_cache_folio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data. At the moment we are not changing the code for non-sleepable context which uses filemap_get_folio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels. Syzbot repro does not crash the kernel anymore and the selftests run successfully. In the follow up we will make __kernel_read() with IOCB_NOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: fix typo in frequency notification The NAN notification is for 5745 MHz which corresponds to channel 149 and not 5475 which is not actually a valid channel. This could result in a NULL pointer dereference in cfg80211_next_nan_dw_notif.
A flaw was found in the Linux kernel's nf_tables component. A logic bug in nft_map_catchall_activate causes an inverted element activity check during the abort path of a failed transaction. This can lead to a use-after-free vulnerability, as catchall verdict elements may still reference a freed chain. A local low privileged user can exploit this to cause a denial of service or potentially achieve privilege escalation.
A flaw was found in the Linux kernel's ice network driver. A local attacker could exploit a race condition during the Virtual Station Interface (VSI) rebuild process. This flaw occurs when the Precision Time Protocol (PTP) periodic work attempts to access uninitialized memory, leading to a NULL pointer dereference. Successful exploitation results in a system crash, causing a Denial of Service (DoS).
A flaw was found in the Linux kernel's Remote Direct Memory Access (RDMA) `umad` (User Mode Access Device) component. A local user can exploit this vulnerability by manipulating input, causing an integer underflow that leads to an out-of-bounds memory write. This memory corruption can result in a denial of service (DoS) by crashing the system, and may also lead to limited information disclosure or data integrity issues.
Loading 2.5 MB of JSON…
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.