rainbutterfly/cve_corpus huggingface dataset:
CVE-2026-45776 Open XDMoD has Broken Access Control via Client-Controlled Session Variable
OpenXDMoD is an open framework for collecting and analyzing HPC metrics. Prior to version 11.0.3, a flaw in Open XDMoD's access control logic allows an attacker to submit a crafted HTTPS POST request that sets a session variable used for authorization decisions. If an installation of Open XDMoD includes the optional Job Performance (SUPReMM) module, an attacker could bypass intended data access restrictions and view other users' compute job efficiency metrics. All deployments of Open XDMoD prior to version 11.0.3 that contain the optional Job Performance (SUPReMM) module are impacted. This issue was reported privately on 2026-04-06, and at this time there is no evidence that this vulnerability has been exploited in the wild. The vulnerability was patched in Open XDMoD 11.0.3 on 2026-05-12. As a workaround, apply the patch manually.
Problem types: cwe_id: CWE-284
description: CWE-284: Improper Access Control
Affected products: vendor: ubccr
product: xdmod
Published: 2026-06-05T19:26:31.288Z
CVE-2026-45777 Open XDMoD Vulnerable to Unauthenticated Remote Code Execution (RCE) via OS Command Injection
OpenXDMoD is an open framework for collecting and analyzing HPC metrics. Starting in version 9.5.0 and prior to version 11.0.3, an attacker can remotely execute arbitrary system commands on the web server hosting Open XDMoD with the privileges of the web server process. This could allow an attacker to read or modify application data, alter system configuration, or disrupt service availability. All deployments of Open XDMoD versions 9.5.0 through 11.0.2 (inclusive) are impacted. This issue was reported privately on 2026-04-06, and at this time there is no evidence that this vulnerability has been exploited in the wild. The vulnerability was patched in Open XDMoD 11.0.3 on 2026-05-12. As a workaround, apply the patch manually.
Problem types: cwe_id: CWE-78
description: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Affected products: vendor: ubccr
product: xdmod
Published: 2026-06-05T19:27:50.626Z
CVE-2026-45778 Open XDMoD Vulnerable to Reflected Cross-Site Scripting (XSS) in Password Reset
OpenXDMoD is an open framework for collecting and analyzing HPC metrics. Prior to version 11.0.3, an authenticated attacker can inject malicious JavaScript into their Open XDMoD user profile and abuse the password reset functionality to email a link to an HTML page, which when visited by the victim, reflects and executes the unsanitized payload in the victim's browser, potentially leading to credential capture and Open XDMoD account takeover. All deployments of Open XDMoD prior to 11.0.3 are impacted. This issue was reported privately on 2026-04-06, and at this time there is no evidence that this vulnerability has been exploited in the wild. The vulnerability was patched in Open XDMoD 11.0.3 on 2026-05-12. As a workaround, apply the patch manually.
Problem types: cwe_id: CWE-79
description: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: ubccr
product: xdmod
Published: 2026-06-05T19:29:18.171Z
CVE-2026-45779 Open XDMoD Vulnerable to Unauthenticated SQL Injection Leading to Full Database Compromise
OpenXDMoD is an open framework for collecting and analyzing HPC metrics. An SQL injection vulnerability exists in Open XDMoD versions prior to 10.0.3 that allows an unauthenticated remote attacker to execute arbitrary SQL statements. Exploitation requires no authentication or user interaction and can result in complete compromise of the underlying database. All deployments of Open XDMoD prior to 10.0.3 are impacted. This issue was discovered on 2023-08-03 and patched on 2023-08-04. At this time there is no evidence that this vulnerability has been exploited in the wild. The vulnerability was patched in Open XDMoD 10.0.3 on 2023-08-04. As a workaround, apply the patch manually.
Problem types: cwe_id: CWE-89
description: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Affected products: vendor: ubccr
product: xdmod
Published: 2026-06-05T19:30:43.429Z
CVE-2026-45781 MCP Registry: OCI ownership validation fails open on upstream rate limits, allowing attacker-controlled package claims
The MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.9, OCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their io.github.<user>/* namespace to OCI images they do not control. internal/validators/registries/oci.go:104-119 fails open on http.StatusTooManyRequests: when the registry's anonymous fetch to the upstream OCI registry is rate-limited, ValidateOCI returns nil and the publish is accepted without ever running the io.modelcontextprotocol.server.name label-match check at lines 122-141. That label check is the only cross-system ownership proof the registry applies to OCI packages — every other registry type (NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error. This vulnerability is fixed in 1.7.9.
Problem types: cwe_id: CWE-636
description: CWE-636: Not Failing Securely ('Failing Open')
Affected products: vendor: modelcontextprotocol
product: registry
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 3.5
baseSeverity: LOW
confidentialityImpact: NONE
integrityImpact: LOW
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N
version: 3.1
Published: 2026-05-14T21:00:49.961Z
CVE-2026-45787 electerm's encrypt method not safe enough
electerm is an open-sourced terminal/ssh/sftp/telnet/serialport/RDP/VNC/Spice/ftp client. Prior to 3.9.5, deterministic AES-192-CBC with a fixed zero IV, constant KDF salt, and no MAC leads to confidentiality and integrity failures for synced bookmark/profile data. Attackers can crack common passwords across installs and perform undetected ciphertext bit-flips to alter config/bookmarks. This vulnerability is fixed in 3.9.5.
Problem types: cwe_id: CWE-326
description: CWE-326: Inadequate Encryption Strength
cwe_id: CWE-329
description: CWE-329: Generation of Predictable IV with CBC Mode
cwe_id: CWE-353
description: CWE-353: Missing Support for Integrity Check
cwe_id: CWE-759
description: CWE-759: Use of a One-Way Hash without a Salt
cwe_id: CWE-916
description: CWE-916: Use of Password Hash With Insufficient Computational Effort
Affected products: vendor: electerm
product: electerm
Published: 2026-05-28T17:17:56.385Z
CVE-2026-45800 Vvveb: Authenticated SQL injection in /user/orders via order_by and direction
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, there is an authenticated SQL injection issue in the frontend user order history page in Vvveb CMS. A normal frontend user can log in and access /user/orders. The order_by and direction request parameters are accepted from the URL, propagated through the Orders component, and directly concatenated into the SQL ORDER BY clause in OrderSQL::getAll(). Because of this, attacker-controlled input reaches SQL structure without a whitelist or safe query construction step. This vulnerability is fixed in 1.0.8.3.
Problem types: cwe_id: CWE-89
description: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Affected products: vendor: givanz
product: Vvveb
Published: 2026-05-15T18:44:38.901Z
CVE-2026-45803 gh: GitHub Actions log output in `gh run view` allows terminal escape sequence injection
`gh` is GitHub’s official command line tool. From 1.6.0 to before 2.92.0, a security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using gh run view --log or gh run view --log-failed. The vulnerability stems from the way GitHub CLI handles raw Actions log output. The gh run view --log and gh run view --log-failed commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user's terminal when they inspect the run. Depending on the victim's terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as screen) potentially execute arbitrary commands. This vulnerability is fixed in 2.92.0.
Problem types: cwe_id: CWE-150
description: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Affected products: vendor: cli
product: cli
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 3.5
baseSeverity: LOW
confidentialityImpact: NONE
integrityImpact: LOW
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N
version: 3.1
Published: 2026-05-15T15:26:56.675Z
CVE-2026-45810 Nextcloud: Propfind requests for file comments allowed to load comments for other files
Nextcloud is an open source content collaboration platform. In Nextcloud Server from versions 31.0.0 to before 31.0.12, and 32.0.0 to before 32.0.3, a missing check of a relation allowed authenticated users with access to any file comment, to read the content of all comments. It is recommended that the Nextcloud Server is upgraded to 31.0.12 or 32.0.3. It is recommended that the Nextcloud Enterprise Server is upgraded to 21.0.9.20, 22.2.10.35, 23.0.12.31, 24.0.12.30, 25.0.13.25, 26.0.13.22, 27.1.11.22, 28.0.14.13, 29.0.16.10, 30.0.17.5, 31.0.12 or 32.0.3
Problem types: cwe_id: CWE-639
description: CWE-639: Authorization Bypass Through User-Controlled Key
Affected products: vendor: nextcloud
product: security-advisories
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 6.8
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: NONE
privilegesRequired: LOW
scope: CHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N
version: 3.1
Published: 2026-06-01T17:13:21.681Z
CVE-2026-45829 
A pre-authentication, code injection vulnerability in version 1.0.0 or later of the ChromaDB Python project allows an unauthenticated attacker to run arbitrary code on the server by sending a malicious model repository and trust_remote_code set to true in the /api/v2/tenants/{tenant}/databases/{db}/collections endpoint.
Problem types: cwe_id: CWE-94
description: CWE-94: Improper Control of Generation of Code ('Code Injection')
Affected products: vendor: Chroma
product: ChromaDB
default_status: unaffected
Credits: lang: en
value: Esteban Tonglet
Published: 2026-05-18T15:59:22.529Z
CVE-2026-45834 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()

Add the same NULL guard already present in
l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-26T16:14:11.198Z
CVE-2026-45835 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()

Add the same NULL guard already present in
l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-26T16:14:12.195Z
CVE-2026-45836 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()

Add the same NULL guard already present in
l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-26T16:14:13.568Z
CVE-2026-45837 bpf: Fix use-after-free in arena_vm_close on fork
In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix use-after-free in arena_vm_close on fork

arena_vm_open() only bumps vml->mmap_count but never registers the
child VMA in arena->vma_list. The vml->vma always points at the
parent VMA, so after parent munmap the pointer dangles. If the child
then calls bpf_arena_free_pages(), zap_pages() reads the stale
vml->vma triggering use-after-free.

Fix this by preventing the arena VMA from being inherited across
fork with VM_DONTCOPY, and preventing VMA splits via the may_split
callback.

Also reject mremap with a .mremap callback returning -EINVAL. A
same-size mremap(MREMAP_FIXED) on the full arena VMA reaches
copy_vma() through the following path:

  check_prep_vma()       - returns 0 early: new_len == old_len
                           skips VM_DONTEXPAND check
  prep_move_vma()        - vm_start == old_addr and
                           vm_end == old_addr + old_len
                           so may_split is never called
  move_vma()
    copy_vma_and_data()
      copy_vma()
        vm_area_dup()    - copies vm_private_data (vml pointer)
        vm_ops->open()   - bumps vml->mmap_count
      vm_ops->mremap()   - returns -EINVAL, rollback unmaps new VMA

The refcount ensures the rollback's arena_vm_close does not free
the vml shared with the original VMA.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:32.833Z
CVE-2026-45838 bpf: fix end-of-list detection in cgroup_storage_get_next_key()
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix end-of-list detection in cgroup_storage_get_next_key()

list_next_entry() never returns NULL -- when the current element is the
last entry it wraps to the list head via container_of(). The subsequent
NULL check is therefore dead code and get_next_key() never returns
-ENOENT for the last element, instead reading storage->key from a bogus
pointer that aliases internal map fields and copying the result to
userspace.

Replace it with list_entry_is_head() so the function correctly returns
-ENOENT when there are no more entries.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:36.561Z
CVE-2026-45839 bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()
In the Linux kernel, the following vulnerability has been resolved:

bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()

CO-RE accessor strings are colon-separated indices that describe a path
from a root BTF type to a target field, e.g. "0:1:2" walks through
nested struct members. bpf_core_parse_spec() parses each component with
sscanf("%d"), so negative values like -1 are silently accepted.  The
subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the
upper bound and always pass for negative values because C integer
promotion converts the __u16 btf_vlen result to int, making the
comparison (int)(-1) >= (int)(N) false for any positive N.

When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff,
producing an out-of-bounds read far past the members array.  A crafted
BPF program with a negative CO-RE accessor on any struct that exists in
vmlinux BTF (e.g. task_struct) crashes the kernel deterministically
during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y
(default on major distributions).  The bug is reachable with CAP_BPF:

 BUG: unable to handle page fault for address: ffffed11818b6626
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 Oops: Oops: 0000 [#1] SMP KASAN NOPTI
 CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full)
 RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354)
 RAX: 00000000ffffffff
 Call Trace:
  <TASK>
  bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321)
  bpf_core_apply (kernel/bpf/btf.c:9507)
  check_core_relo (kernel/bpf/verifier.c:19475)
  bpf_check (kernel/bpf/verifier.c:26031)
  bpf_prog_load (kernel/bpf/syscall.c:3089)
  __sys_bpf (kernel/bpf/syscall.c:6228)
  </TASK>

CO-RE accessor indices are inherently non-negative (struct member index,
array element index, or enumerator index), so reject them immediately
after parsing.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:37.855Z
CVE-2026-45840 openvswitch: cap upcall PID array size and pre-size vport replies
In the Linux kernel, the following vulnerability has been resolved:

openvswitch: cap upcall PID array size and pre-size vport replies

The vport netlink reply helpers allocate a fixed-size skb with
nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
array via ovs_vport_get_upcall_portids().  Since
ovs_vport_set_upcall_portids() accepts any non-zero multiple of
sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
array large enough to overflow the reply buffer, causing nla_put() to
fail with -EMSGSIZE and hitting BUG_ON(err < 0).  On systems with
unprivileged user namespaces enabled (e.g., Ubuntu default), this is
reachable via unshare -Urn since OVS vport mutation operations use
GENL_UNS_ADMIN_PERM.

 kernel BUG at net/openvswitch/datapath.c:2414!
 Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
 CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
 Call Trace:
  <TASK>
  genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
  genl_rcv_msg (net/netlink/genetlink.c:1194)
  netlink_rcv_skb (net/netlink/af_netlink.c:2550)
  genl_rcv (net/netlink/genetlink.c:1219)
  netlink_unicast (net/netlink/af_netlink.c:1344)
  netlink_sendmsg (net/netlink/af_netlink.c:1894)
  __sys_sendto (net/socket.c:2206)
  __x64_sys_sendto (net/socket.c:2209)
  do_syscall_64 (arch/x86/entry/syscall_64.c:63)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>
 Kernel panic - not syncing: Fatal exception

Reject attempts to set more PIDs than nr_cpu_ids in
ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply
size in ovs_vport_cmd_msg_size() based on that bound, similar to the
existing ovs_dp_cmd_msg_size().  nr_cpu_ids matches the cap already
used by the per-CPU dispatch configuration on the datapath side
(ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the
two sides stay consistent.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:39.478Z
CVE-2026-45841 netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO

nf_osf_match_one() computes ctx->window % f->wss.val in the
OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A
CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a
subsequent matching TCP SYN divides by zero and panics the kernel.

Reject the bogus fingerprint in nfnl_osf_add_callback() above the
per-option for-loop. f->wss is per-fingerprint, not per-option, so
the check must run regardless of f->opt_num (including 0). Also
reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that
as "should not happen".

Crash:
 Oops: divide error: 0000 [#1] SMP KASAN NOPTI
 RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)
 Call Trace:
 <IRQ>
  nf_osf_match (net/netfilter/nfnetlink_osf.c:220)
  xt_osf_match_packet (net/netfilter/xt_osf.c:32)
  ipt_do_table (net/ipv4/netfilter/ip_tables.c:348)
  nf_hook_slow (net/netfilter/core.c:622)
  ip_local_deliver (net/ipv4/ip_input.c:265)
  ip_rcv (include/linux/skbuff.h:1162)
  __netif_receive_skb_one_core (net/core/dev.c:6181)
  process_backlog (net/core/dev.c:6642)
  __napi_poll (net/core/dev.c:7710)
  net_rx_action (net/core/dev.c:7945)
  handle_softirqs (kernel/softirq.c:622)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:40.805Z
CVE-2026-45842 slip: reject VJ receive packets on instances with no rstate array
In the Linux kernel, the following vulnerability has been resolved:

slip: reject VJ receive packets on instances with no rstate array

slhc_init() accepts rslots == 0 as a valid configuration, with the
documented meaning of 'no receive compression'. In that case the
allocation loop in slhc_init() is skipped, so comp->rstate stays
NULL and comp->rslot_limit stays 0 (from the kzalloc of struct
slcompress).

The receive helpers do not defend against that configuration.
slhc_uncompress() dereferences comp->rstate[x] when the VJ header
carries an explicit connection ID, and slhc_remember() later assigns
cs = &comp->rstate[...] after only comparing the packet's slot number
to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the
range check, and the code dereferences a NULL rstate.

The configuration is reachable in-tree through PPP. PPPIOCSMAXCID
stores its argument in a signed int, and (val >> 16) uses arithmetic
shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1
is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because
/dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path
is reachable from an unprivileged user namespace. Once the malformed
VJ state is installed, any inbound VJ-compressed or VJ-uncompressed
frame that selects slot 0 crashes the kernel in softirq context:

 Oops: general protection fault, probably for non-canonical
       address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
 RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519)
 Call Trace:
  <TASK>
  ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466)
  ppp_input (drivers/net/ppp/ppp_generic.c:2359)
  ppp_async_process (drivers/net/ppp/ppp_async.c:492)
  tasklet_action_common (kernel/softirq.c:926)
  handle_softirqs (kernel/softirq.c:623)
  run_ksoftirqd (kernel/softirq.c:1055)
  smpboot_thread_fn (kernel/smpboot.c:160)
  kthread (kernel/kthread.c:436)
  ret_from_fork (arch/x86/kernel/process.c:164)
  </TASK>

Reject the receive side on such instances instead of touching rstate.
slhc_uncompress() falls through to its existing 'bad' label, which
bumps sls_i_error and enters the toss state. slhc_remember() mirrors
that with an explicit sls_i_error increment followed by slhc_toss();
the sls_i_runt counter is not used here because a missing rstate is
an internal configuration state, not a runt packet.

The transmit path is unaffected: the only in-tree caller that picks
rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and
slip.c always calls slhc_init(16, 16), so comp->tstate remains valid
and slhc_compress() continues to work.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T09:24:42.637Z