RHSA-2026:18134
Vulnerability from csaf_redhat - Published: 2026-05-19 09:04 - Updated: 2026-10-30 22:44In 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---
A flaw was found in the CephX authentication protocol used by Ceph, a distributed storage system. CephX uses AES-128-CBC encryption with a hardcoded initialization vector and no message authentication (HMAC), making it vulnerable to the same class of unauthenticated-encryption attacks that compromised Kerberos 4 as documented in MIT's 2004 PERILS paper. An attacker who has compromised a single low-privilege CephX entity key can use the Ceph monitor as an encryption oracle by requesting tickets for specially-named entity identities over a standard network connection. The monitor encrypts these attacker-controlled names into ciphertext blocks which, due to absent integrity protection, can be spliced into forged credentials for privileged entities such as OSDs, MDSs, and MGRs. This grants cluster-wide access including data reads, data corruption, and full administrative control.
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 LifetimeA flaw was found in the Linux kernel. A local privileged user can cause a Denial of Service (DoS) by triggering a kernel crash. When a Berkeley Packet Filter (BPF) program attached to a kernel Transport Layer Security (kTLS) socket modifies message data and encounters socket corking, the kernel incorrectly calculates buffer rollback boundaries. This inconsistency triggers a kernel panic, causing the system to crash.
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 LifetimeA flaw was found in the Linux kernel's Function Tracer (ftrace) subsystem. When an internal error disables function tracing and a kernel module is subsequently removed, the kernel fails to properly release tracking references associated with the unloaded module. A local user querying the kernel symbol table can trigger a use-after-free condition by accessing this deallocated memory, leading to a system crash and causing a Denial of Service (DoS).
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]
A flaw was found in the Linux kernel's VLAN (Virtual Local Area Network) implementation. This vulnerability allows an authorized local user with network administration privileges to cause a Denial of Service (DoS) through a kernel crash or system memory exhaustion. The issue stems from a reference counting imbalance when dynamically toggling receiver VLAN filtering on active network interfaces.
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.
A flaw was found in the Linux kernel. A race condition in the writeback subsystem can lead to a use-after-free vulnerability when an inode's writeback structure is concurrently switched. A local attacker with administrative privileges could trigger this flaw during writeback management operations to crash the kernel, resulting in a denial of service (DoS) or potentially allowing arbitrary code execution in the kernel context.
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.7 MB of JSON…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.