rainbutterfly/cve_corpus huggingface dataset:
CVE-2026-45965 apparmor: fix invalid deref of rawdata when export_binary is unset
In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix invalid deref of rawdata when export_binary is unset

If the export_binary parameter is disabled on runtime, profiles that
were loaded before that will still have their rawdata stored in
apparmorfs, with a symbolic link to the rawdata on the policy
directory. When one of those profiles are replaced, the rawdata is set
to NULL, but when trying to resolve the symbolic links to rawdata for
that profile, it will try to dereference profile->rawdata->name when
profile->rawdata is now NULL causing an oops. Fix it by checking if
rawdata is set.

[  168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088
[  168.657420] #PF: supervisor read access in kernel mode
[  168.660619] #PF: error_code(0x0000) - not-present page
[  168.663613] PGD 0 P4D 0
[  168.665450] Oops: Oops: 0000 [#1] SMP NOPTI
[  168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)
[  168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330
[  168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8
[  168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282
[  168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158
[  168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80
[  168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000
[  168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80
[  168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0
[  168.697637] FS:  0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000
[  168.699227] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0
[  168.701696] Call Trace:
[  168.702325]  <TASK>
[  168.702995]  rawdata_get_link_data+0x1c/0x30
[  168.704145]  vfs_readlink+0xd4/0x160
[  168.705152]  do_readlinkat+0x114/0x180
[  168.706214]  __x64_sys_readlink+0x1e/0x30
[  168.708653]  x64_sys_call+0x1d77/0x26b0
[  168.709525]  do_syscall_64+0x81/0x500
[  168.710348]  ? do_statx+0x72/0xb0
[  168.711109]  ? putname+0x3e/0x80
[  168.711845]  ? __x64_sys_statx+0xb7/0x100
[  168.712711]  ? x64_sys_call+0x10fc/0x26b0
[  168.713577]  ? do_syscall_64+0xbf/0x500
[  168.714412]  ? do_user_addr_fault+0x1d2/0x8d0
[  168.715404]  ? irqentry_exit+0xb2/0x740
[  168.716359]  ? exc_page_fault+0x90/0x1b0
[  168.717307]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:23.170Z
CVE-2026-45966 apparmor: fix NULL pointer dereference in __unix_needs_revalidation
In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix NULL pointer dereference in __unix_needs_revalidation

When receiving file descriptors via SCM_RIGHTS, both the socket pointer
and the socket's sk pointer can be NULL during socket setup or teardown,
causing NULL pointer dereferences in __unix_needs_revalidation().

This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new
__unix_needs_revalidation() function was added without proper NULL checks.

The crash manifests as:
  BUG: kernel NULL pointer dereference, address: 0x0000000000000018
  RIP: aa_file_perm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0)
  Call Trace:
   apparmor_file_receive+0x42/0x80
   security_file_receive+0x2e/0x50
   receive_fd+0x1d/0xf0
   scm_detach_fds+0xad/0x1c0

The function dereferences sock->sk->sk_family without checking if either
sock or sock->sk is NULL first.

Add NULL checks for both sock and sock->sk before accessing sk_family.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:24.300Z
CVE-2026-45967 bpf: Return proper address for non-zero offsets in insn array
In the Linux kernel, the following vulnerability has been resolved:

bpf: Return proper address for non-zero offsets in insn array

The map_direct_value_addr() function of the instruction
array map incorrectly adds offset to the resulting address.
This is a bug, because later the resolve_pseudo_ldimm64()
function adds the offset. Fix it. Corresponding selftests
are added in a consequent commit.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:25.572Z
CVE-2026-45968 cpuidle: Skip governor when only one idle state is available
In the Linux kernel, the following vulnerability has been resolved:

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node),
cpuidle may register only a single idle state. In cases where that
single state is a polling state (state 0), the ladder governor may
incorrectly treat state 1 as the first usable state and pass an
out-of-bounds index. This can lead to a NULL enter callback being
invoked, ultimately resulting in a system crash.

[   13.342636] cpuidle-powernv : Only Snooze is available
[   13.351854] Faulting instruction address: 0x00000000
[   13.376489] NIP [0000000000000000] 0x0
[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668

Fix this by adding a bail-out in cpuidle_select() that returns state 0
directly when state_count <= 1, bypassing the governor and keeping the
tick running.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:27.247Z
CVE-2026-45969 HID: playstation: Add missing check for input_ff_create_memless
In the Linux kernel, the following vulnerability has been resolved:

HID: playstation: Add missing check for input_ff_create_memless

The ps_gamepad_create() function calls input_ff_create_memless()
without verifying its return value,  which can lead to incorrect
behavior or potential crashes when FF effects are triggered.

Add a check for the return value of input_ff_create_memless().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:28.112Z
CVE-2026-45971 bpf: Limit bpf program signature size
In the Linux kernel, the following vulnerability has been resolved:

bpf: Limit bpf program signature size

Practical BPF signatures are significantly smaller than
KMALLOC_MAX_CACHE_SIZE

Allowing larger sizes opens the door for abuse by passing excessive
size values and forcing the kernel into expensive allocation paths (via
kmalloc_large or vmalloc).
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:30.651Z
CVE-2026-45972 smb: client: fix potential UAF and double free in smb2_open_file()
In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential UAF and double free in smb2_open_file()

Zero out @err_iov and @err_buftype before retrying SMB2_open() to
prevent an UAF bug if @data != NULL, otherwise a double free.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
baseScore: 9.8
baseSeverity: CRITICAL
Published: 2026-05-27T12:18:31.500Z
CVE-2026-45973 RDMA/mlx5: Fix UMR hang in LAG error state unload
In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix UMR hang in LAG error state unload

During firmware reset in LAG mode, a race condition causes the driver
to hang indefinitely while waiting for UMR completion during device
unload. See [1].

In LAG mode the bond device is only registered on the master, so it
never sees sys_error events from the slave.
During firmware reset this causes UMR waits to hang forever on unload
as the slave is dead but the master hasn't entered error state yet, so
UMR posts succeed but completions never arrive.

Fix this by adding a sys_error notifier that gets registered before
MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device().
This ensures error events reach the bond device throughout teardown.

[1]
Call Trace:
 __schedule+0x2bd/0x760
 schedule+0x37/0xa0
 schedule_preempt_disabled+0xa/0x10
 __mutex_lock.isra.6+0x2b5/0x4a0
 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib]
 ? __xa_erase+0x4a/0xa0
 ? _cond_resched+0x15/0x30
 ? wait_for_completion+0x31/0x100
 ib_dereg_mr_user+0x48/0xc0 [ib_core]
 ? rdmacg_uncharge_hierarchy+0xa0/0x100
 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs]
 uverbs_destroy_uobject+0x37/0x150 [ib_uverbs]
 __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs]
 uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs]
 ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
 remove_client_context+0x8b/0xd0 [ib_core]
 disable_device+0x8c/0x130 [ib_core]
 __ib_unregister_device+0x10d/0x180 [ib_core]
 ib_unregister_device+0x21/0x30 [ib_core]
 __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib]
 auxiliary_bus_remove+0x1e/0x30
 device_release_driver_internal+0x103/0x1f0
 bus_remove_device+0xf7/0x170
 device_del+0x181/0x410
 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core]
 mlx5_disable_lag+0x253/0x260 [mlx5_core]
 mlx5_lag_disable_change+0x89/0xc0 [mlx5_core]
 mlx5_eswitch_disable+0x67/0xa0 [mlx5_core]
 mlx5_unload+0x15/0xd0 [mlx5_core]
 mlx5_unload_one+0x71/0xc0 [mlx5_core]
 mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core]
 process_one_work+0x1a7/0x360
 worker_thread+0x30/0x390
 ? create_worker+0x1a0/0x1a0
 kthread+0x116/0x130
 ? kthread_flush_work_fn+0x10/0x10
 ret_from_fork+0x22/0x40
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:32.270Z
CVE-2026-45974 btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found
In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found

If btrfs_search_slot_for_read() returns 1, it means we did not find any
key greater than or equals to the key we asked for, meaning we have
reached the end of the tree and therefore the path is not valid. If
this happens we need to break out of the loop and stop, instead of
continuing and accessing an invalid path.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:33.107Z
CVE-2026-45975 ublk: use READ_ONCE() to read struct ublksrv_ctrl_cmd
In the Linux kernel, the following vulnerability has been resolved:

ublk: use READ_ONCE() to read struct ublksrv_ctrl_cmd

struct ublksrv_ctrl_cmd is part of the io_uring_sqe, which may lie in
userspace-mapped memory. It's racy to access its fields with normal
loads, as userspace may write to them concurrently. Use READ_ONCE() to
copy the ublksrv_ctrl_cmd from the io_uring_sqe to the stack. Use the
local copy in place of the one in the io_uring_sqe.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:33.939Z
CVE-2026-45976 drm/amdgpu: Fix memory leak in amdgpu_ras_init()
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix memory leak in amdgpu_ras_init()

When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function
returns directly without freeing the allocated con structure, leading
to a memory leak.

Fix this by jumping to the release_con label to properly clean up the
allocated memory before returning the error code.

Compile tested only. Issue found using a prototype static analysis tool
and code review.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:34.772Z
CVE-2026-45977 fbnic: close fw_log race between users and teardown
In the Linux kernel, the following vulnerability has been resolved:

fbnic: close fw_log race between users and teardown

Fixes a theoretical race on fw_log between the teardown path and fw_log
write functions.

fw_log is written inside fbnic_fw_log_write() and can be reached from
the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before
IRQ/MBX teardown during cleanup, resulting in a potential data race of
dereferencing a freed/null variable.

Possible Interleaving Scenario:
  CPU0: fbnic_fw_msix_intr() // Entry
          fbnic_fw_log_write()
            if (fbnic_fw_log_ready())   // true
            ... preempt ...
  CPU1: fbnic_remove() // Entry
          fbnic_fw_log_free()
            vfree(log->data_start);
            log->data_start = NULL;
  CPU0: continues, walks log->entries or writes to log->data_start

The initialization also has an incorrect order problem, as the fw_log
is currently allocated after MBX setup during initialization.
Fix the problems by adjusting the synchronization order to put
initialization in place before the mailbox is enabled, and not cleared
until after the mailbox has been disabled.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:35.858Z
CVE-2026-45978 staging: greybus: lights: avoid NULL deref
In the Linux kernel, the following vulnerability has been resolved:

staging: greybus: lights: avoid NULL deref

gb_lights_light_config() stores channel_count before allocating the
channels array. If kcalloc() fails, gb_lights_release() iterates the
non-zero count and dereferences light->channels, which is NULL.

Allocate channels first and only then publish channels_count so the
cleanup path can't walk a NULL pointer.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:36.753Z
CVE-2026-45979 drm/amdgpu: clean up the amdgpu_cs_parser_bos
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: clean up the amdgpu_cs_parser_bos

In low memory conditions, kmalloc can fail. In such conditions
unlock the mutex for a clean exit.

We do not need to amdgpu_bo_list_put as it's been handled in the
amdgpu_cs_parser_fini.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:37.936Z
CVE-2026-45980 accel/amdxdna: Stop job scheduling across aie2_release_resource()
In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: Stop job scheduling across aie2_release_resource()

Running jobs on a hardware context while it is in the process of
releasing resources can lead to use-after-free and crashes.

Fix this by stopping job scheduling before calling
aie2_release_resource() and restarting it after the release completes.
Additionally, aie2_sched_job_run() now checks whether the hardware
context is still active.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
baseScore: 7.8
baseSeverity: HIGH
Published: 2026-05-27T12:18:39.136Z
CVE-2026-45981 s390/cio: Fix device lifecycle handling in css_alloc_subchannel()
In the Linux kernel, the following vulnerability has been resolved:

s390/cio: Fix device lifecycle handling in css_alloc_subchannel()

`css_alloc_subchannel()` calls `device_initialize()` before setting up
the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails,
the error path frees the subchannel structure directly, bypassing
the device model reference counting.

Once `device_initialize()` has been called, the embedded struct device
must be released via `put_device()`, allowing the release callback to
free the container structure.

Fix the error path by dropping the initial device reference with
`put_device()` instead of calling `kfree()` directly.

This ensures correct device lifetime handling and avoids potential
use-after-free or double-free issues.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:39.923Z
CVE-2026-45982 ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()

Cover a missed execution path with a new check.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:40.822Z
CVE-2026-45983 nfsd: never defer requests during idmap lookup
In the Linux kernel, the following vulnerability has been resolved:

nfsd: never defer requests during idmap lookup

During v4 request compound arg decoding, some ops (e.g. SETATTR)
can trigger idmap lookup upcalls. When those upcall responses get
delayed beyond the allowed time limit, cache_check() will mark the
request for deferral and cause it to be dropped.

This prevents nfs4svc_encode_compoundres from being executed, and
thus the session slot flag NFSD4_SLOT_INUSE never gets cleared.
Subsequent client requests will fail with NFSERR_JUKEBOX, given
that the slot will be marked as in-use, making the SEQUENCE op
fail.

Fix this by making sure that the RQ_USEDEFERRAL flag is always
clear during nfs4svc_decode_compoundargs(), since no v4 request
should ever be deferred.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:41.619Z
CVE-2026-45984 gfs2: Fix use-after-free in iomap inline data write path
In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in
gfs2_iomap_begin() via release_metapath() while iomap->inline_data
still points to dibh->b_data. This causes a use-after-free when
iomap_write_end_inline() later attempts to write to the inline data
area.

The bug sequence:
1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode
   metadata into dibh
2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)
3. Calls release_metapath() which calls brelse(dibh), dropping refcount
   to 0
4. kswapd reclaims the page (~39ms later in the syzbot report)
5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data
6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount
with get_bh() in gfs2_iomap_begin(). The buffer is then properly
released in gfs2_iomap_end() after the inline write completes,
ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based
on analysis of the KASAN report and code review showing the buffer head
is freed before use.

[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid
leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
baseScore: 7.8
baseSeverity: HIGH
Published: 2026-05-27T12:18:42.964Z
CVE-2026-45985 ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O
In the Linux kernel, the following vulnerability has been resolved:

ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with
dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an
existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was
set when calling ext4_split_convert_extents(), which may potentially
result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

   [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent
   [UUUUUUUUUUUUUUUU] extent status tree
            |<-   ->| ----> dio write this range

First, ext4_iomap_alloc() call ext4_map_blocks() with
EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and
EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and
call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the
above flags set.

Then, ext4_split_convert_extents() calls ext4_split_extent() with
EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2
flags set, and it calls ext4_split_extent_at() to split the second half
with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT
and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()
failed to insert extent since a temporary lack -ENOSPC. It zeroes out
the first half but convert the entire on-disk extent to written since
the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten
in the extent status tree.

   [0000000000SSSSSS]  data                S: stale data, 0: zeroed
   [WWWWWWWWWWWWWWWW]  on-disk extent      W: written extent
   [WWWWWWWWWWUUUUUU]  extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in
the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting
an unwritten extent before submitting I/O, and make
ext4_split_convert_extents() to zero out the entire extent range
to zero for this case, and also mark the extent in the extent status
tree for consistency.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:18:43.844Z
CVE-2026-45986 crypto: ccree - fix a memory leak in cc_mac_digest()
In the Linux kernel, the following vulnerability has been resolved:

crypto: ccree - fix a memory leak in cc_mac_digest()

Add cc_unmap_result() if cc_map_hash_request_final()
fails to prevent potential memory leak.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-05-27T12:55:35.838Z