Medium · CVSS 6.9
VB-Audio Voicemeeter, Voicemeeter Banana, and Voicemeeter Potato (versions ending in 1.1.1.9, 2.1.1.9, and 3.1.1.9 and earlier, respectively), as well as VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a vulnerability in their virtual audio drivers (vbvoicemeetervaio64*.sys, vbmatrixvaio64*.sys, vbaudio_vmauxvaio*.sys, vbaudio_vmvaio*.sys, and vbaudio_vmvaio3*.sys). When a handle is opened with a special file attribute value, the drivers improperly initialize FILE_OBJECT->FsContext to a non-pointer magic value. If subsequent operations are not handled by the VB-Audio driver and are forwarded down the audio driver stack (e.g., via PortCls to ks.sys), the invalid FsContext value can be dereferenced, causing a kernel crash (BSoD), typically SYSTEM_SERVICE_EXCEPTION with STATUS_ACCESS_VIOLATION. This flaw allows a local unprivileged user to trigger a denial-of-service on affected Windows systems.
Published Jan 22, 2026 · Updated May 14, 2026
High · CVSS 8.4
D-Link D-View 8 versions 2.0.1.107 and below contain an uncontrolled search path vulnerability in the installer. When executed with elevated privileges via UAC, the installer attempts to load version.dll from its execution directory, allowing DLL preloading. An attacker can supply a malicious version.dll alongside the legitimate installer so that, when a victim runs the installer and approves the UAC prompt, attacker-controlled code executes with administrator privileges. This can lead to full system compromise.
Published Jan 21, 2026 · Updated May 14, 2026
High · CVSS 8.7
D-Link D-View 8 versions 2.0.1.107 and below contain an improper access control vulnerability in backend API endpoints. Any authenticated user can supply an arbitrary user_id value to retrieve sensitive credential data belonging to other users, including super administrators. The exposed credential material can be reused directly as a valid authentication secret, allowing full impersonation of the targeted account. This results in complete account takeover and full administrative control over the D-View system.
Published Jan 21, 2026 · Updated May 14, 2026
Critical · CVSS 9.3
Entrust Instant Financial Issuance (IFI) On Premise software (formerly referred to as CardWizard) versions 5.x, prior to 6.10.5, and prior to 6.11.1 contain an insecure .NET Remoting exposure in the SmartCardController service (DCG.SmartCardControllerService.exe). The service registers a TCP remoting channel with unsafe formatter/settings that permit untrusted remoting object invocation. A remote, unauthenticated attacker who can reach the remoting port can invoke exposed remoting objects to read arbitrary files from the server and coerce outbound authentication, and may achieve arbitrary file write and remote code execution via known .NET Remoting exploitation techniques. This can lead to disclosure of sensitive installation and service-account data and compromise of the affected host.
Published Jan 15, 2026 · Updated May 14, 2026
Medium · CVSS 5.3
Issue summary: A type confusion vulnerability exists in the signature
verification of signed PKCS#7 data where an ASN1_TYPE union member is
accessed without first validating the type, causing an invalid or NULL
pointer dereference when processing malformed PKCS#7 data.
Impact summary: An application performing signature verification of PKCS#7
data or calling directly the PKCS7_digest_from_attributes() function can be
caused to dereference an invalid or NULL pointer when reading, resulting in
a Denial of Service.
The function PKCS7_digest_from_attributes() accesses the message digest attribute
value without validating its type. When the type is not V_ASN1_OCTET_STRING,
this results in accessing invalid memory through the ASN1_TYPE union, causing
a crash.
Exploiting this vulnerability requires an attacker to provide a malformed
signed PKCS#7 to an application that verifies it. The impact of the
exploit is just a Denial of Service, the PKCS7 API is legacy and applications
should be using the CMS API instead. For these reasons the issue was
assessed as Low severity.
The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module
boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Published Jan 27, 2026 · Updated May 12, 2026
Medium · CVSS 5.5
Issue summary: An invalid or NULL pointer dereference can happen in
an application processing a malformed PKCS#12 file.
Impact summary: An application processing a malformed PKCS#12 file can be
caused to dereference an invalid or NULL pointer on memory read, resulting
in a Denial of Service.
A type confusion vulnerability exists in PKCS#12 parsing code where
an ASN1_TYPE union member is accessed without first validating the type,
causing an invalid pointer read.
The location is constrained to a 1-byte address space, meaning any
attempted pointer manipulation can only target addresses between 0x00 and 0xFF.
This range corresponds to the zero page, which is unmapped on most modern
operating systems and will reliably result in a crash, leading only to a
Denial of Service. Exploiting this issue also requires a user or application
to process a maliciously crafted PKCS#12 file. It is uncommon to accept
untrusted PKCS#12 files in applications as they are usually used to store
private keys which are trusted by definition. For these reasons, the issue
was assessed as Low severity.
The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.
OpenSSL 1.0.2 is not affected by this issue.
Published Jan 27, 2026 · Updated May 12, 2026
Low · CVSS 3.1
Vulnerability in Oracle Java SE (component: JavaFX). Supported versions that are affected are Oracle Java SE: 8u471-b50. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).
Published Jan 20, 2026 · Updated May 12, 2026
Medium · CVSS 6.1
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u471, 8u471-b50, 8u471-perf, 11.0.29, 17.0.17, 21.0.9, 25.0.1; Oracle GraalVM for JDK: 17.0.17 and 21.0.9; Oracle GraalVM Enterprise Edition: 21.3.16. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
Published Jan 20, 2026 · Updated May 12, 2026
Medium · CVSS 4.8
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: RMI). Supported versions that are affected are Oracle Java SE: 8u471, 8u471-b50, 8u471-perf, 11.0.29, 17.0.17, 21.0.9, 25.0.1; Oracle GraalVM for JDK: 17.0.17 and 21.0.9; Oracle GraalVM Enterprise Edition: 21.3.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
Published Jan 20, 2026 · Updated May 12, 2026
Medium · CVSS 4.6
alsa-lib versions 1.2.2 up to and including 1.2.15.2, prior to commit 5f7fe33, contain a heap-based buffer overflow in the topology mixer control decoder. The tplg_decode_control_mixer1() function reads the num_channels field from untrusted .tplg data and uses it as a loop bound without validating it against the fixed-size channel array (SND_TPLG_MAX_CHAN). A crafted topology file with an excessive num_channels value can cause out-of-bounds heap writes, leading to a crash.
Published Jan 29, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
drm/gud: fix NULL fb and crtc dereferences on USB disconnect
On disconnect drm_atomic_helper_disable_all() is called which
sets both the fb and crtc for a plane to NULL before invoking a commit.
This causes a kernel oops on every display disconnect.
Add guards for those dereferences.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
btrfs: release path before iget_failed() in btrfs_read_locked_inode()
In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to
the 'out' label with a path that has a read locked leaf and then we call
iget_failed(). This can result in a ABBA deadlock, since iget_failed()
triggers inode eviction and that causes the release of the delayed inode,
which must lock the delayed inode's mutex, and a task updating a delayed
inode starts by taking the node's mutex and then modifying the inode's
subvolume btree.
Syzbot reported the following lockdep splat for this:
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
btrfs-cleaner/8725 is trying to acquire lock:
ffff0000d6826a48 (&delayed_node->mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
but task is already holding lock:
ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{4:4}:
__lock_release kernel/locking/lockdep.c:5574 [inline]
lock_release+0x198/0x39c kernel/locking/lockdep.c:5889
up_read+0x24/0x3c kernel/locking/rwsem.c:1632
btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169
btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [inline]
btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133
btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395
__btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032
btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [inline]
__btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141
__btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176
btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219
flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828
do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158
btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226
process_one_work+0x7e8/0x155c kernel/workqueue.c:3263
process_scheduled_works kernel/workqueue.c:3346 [inline]
worker_thread+0x958/0xed8 kernel/workqueue.c:3427
kthread+0x5fc/0x75c kernel/kthread.c:463
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844
-> #0 (&delayed_node->mutex){+.+.}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237
lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868
__mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598
__mutex_lock kernel/locking/mutex.c:760 [inline]
mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812
__btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [inline]
btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326
btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587
evict+0x414/0x928 fs/inode.c:810
iput_final fs/inode.c:1914 [inline]
iput+0x95c/0xad4 fs/inode.c:1966
iget_failed+0xec/0x134 fs/bad_inode.c:248
btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101
btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837
btrfs_run_defrag_inode fs/btrfs/defrag.c:237 [inline]
btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf
---truncated---
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv
mlx5e_priv is an unstable structure that can be memset(0) if profile
attaching fails.
Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a
valid netdev.
On mlx5e_remove: Check validity of priv->profile, before attempting
to cleanup any resources that might be not there.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due
to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev
Error: mlx5_core: Failed setting eswitch to offloads.
dmesg:
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000370
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100
RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286
RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0
RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10
R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0
R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400
FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0
Call Trace:
<TASK>
mlx5e_remove+0x57/0x110
device_release_driver_internal+0x19c/0x200
bus_remove_device+0xc6/0x130
device_del+0x160/0x3d0
? devl_param_driverinit_value_get+0x2d/0x90
mlx5_detach_device+0x89/0xe0
mlx5_unload_one_devl_locked+0x3a/0x70
mlx5_devlink_reload_down+0xc8/0x220
devlink_reload+0x7d/0x260
devlink_nl_reload_doit+0x45b/0x5a0
genl_family_rcv_msg_doit+0xe8/0x140
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: Fix fence reference leak on queue teardown v2
The user mode queue keeps a pointer to the most recent fence in
userq->last_fence. This pointer holds an extra dma_fence reference.
When the queue is destroyed, we free the fence driver and its xarray,
but we forgot to drop the last_fence reference.
Because of the missing dma_fence_put(), the last fence object can stay
alive when the driver unloads. This leaves an allocated object in the
amdgpu_userq_fence slab cache and triggers
This is visible during driver unload as:
BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()
kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects
Call Trace:
kmem_cache_destroy
amdgpu_userq_fence_slab_fini
amdgpu_exit
__do_sys_delete_module
Fix this by putting userq->last_fence and clearing the pointer during
amdgpu_userq_fence_driver_free().
This makes sure the fence reference is released and the slab cache is
empty when the module exits.
v2: Update to only release userq->last_fence with dma_fence_put()
(Christian)
(cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Fix kvm_device leak in kvm_eiointc_destroy()
In kvm_ioctl_create_device(), kvm_device has allocated memory,
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but kvm_eiointc_destroy() is not currently doing this, that
would lead to a memory leak.
So, fix it.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Fix kvm_device leak in kvm_ipi_destroy()
In kvm_ioctl_create_device(), kvm_device has allocated memory,
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but kvm_ipi_destroy() is not currently doing this, that
would lead to a memory leak.
So, fix it.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Fix kvm_device leak in kvm_pch_pic_destroy()
In kvm_ioctl_create_device(), kvm_device has allocated memory,
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but kvm_pch_pic_destroy() is not currently doing this, that
would lead to a memory leak.
So, fix it.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak of flow steer list on rmmod
The flow steering list maintains entries that are added and removed as
ethtool creates and deletes flow steering rules. Module removal with active
entries causes memory leak as the list is not properly cleaned up.
Prevent this by iterating through the remaining entries in the list and
freeing the associated memory during module removal. Add a spinlock
(flow_steer_list_lock) to protect the list access from multiple threads.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak in idpf_vport_rel()
Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory
during a reset. Reported by kmemleak:
unreferenced object 0xff450acac838a000 (size 4096):
comm "kworker/u258:5", pid 7732, jiffies 4296830044
hex dump (first 32 bytes):
00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................
backtrace (crc 3da81902):
__kmalloc_cache_noprof+0x469/0x7a0
idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]
idpf_init_task+0x1ec/0x8d0 [idpf]
process_one_work+0x226/0x6d0
worker_thread+0x19e/0x340
kthread+0x10f/0x250
ret_from_fork+0x251/0x2b0
ret_from_fork_asm+0x1a/0x30
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak in idpf_vc_core_deinit()
Make sure to free hw->lan_regs. Reported by kmemleak during reset:
unreferenced object 0xff1b913d02a936c0 (size 96):
comm "kworker/u258:14", pid 2174, jiffies 4294958305
hex dump (first 32 bytes):
00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00 ......-.........
00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff ..@.......%...-.
backtrace (crc 36063c4f):
__kmalloc_noprof+0x48f/0x890
idpf_vc_core_init+0x6ce/0x9b0 [idpf]
idpf_vc_event_task+0x1fb/0x350 [idpf]
process_one_work+0x226/0x6d0
worker_thread+0x19e/0x340
kthread+0x10f/0x250
ret_from_fork+0x251/0x2b0
ret_from_fork_asm+0x1a/0x30
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix error handling in the init_task on load
If the init_task fails during a driver load, we end up without vports and
netdevs, effectively failing the entire process. In that state a
subsequent reset will result in a crash as the service task attempts to
access uninitialized resources. Following trace is from an error in the
init_task where the CREATE_VPORT (op 501) is rejected by the FW:
[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated
[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)
[40958.148190] idpf 0000:83:00.0: HW reset detected
[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8
...
[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]
[40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]
...
[40958.177932] Call Trace:
[40958.178491] <TASK>
[40958.179040] process_one_work+0x226/0x6d0
[40958.179609] worker_thread+0x19e/0x340
[40958.180158] ? __pfx_worker_thread+0x10/0x10
[40958.180702] kthread+0x10f/0x250
[40958.181238] ? __pfx_kthread+0x10/0x10
[40958.181774] ret_from_fork+0x251/0x2b0
[40958.182307] ? __pfx_kthread+0x10/0x10
[40958.182834] ret_from_fork_asm+0x1a/0x30
[40958.183370] </TASK>
Fix the error handling in the init_task to make sure the service and
mailbox tasks are disabled if the error happens during load. These are
started in idpf_vc_core_init(), which spawns the init_task and has no way
of knowing if it failed. If the error happens on reset, following
successful driver load, the tasks can still run, as that will allow the
netdevs to attempt recovery through another reset. Stop the PTP callbacks
either way as those will be restarted by the call to idpf_vc_core_init()
during a successful reset.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
inet: frags: drop fraglist conntrack references
Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging
leaked skbs/conntrack references more obvious.
syzbot reports this as triggering, and I can also reproduce this via
ip_defrag.sh selftest:
conntrack cleanup blocked for 60s
WARNING: net/netfilter/nf_conntrack_core.c:2512
[..]
conntrack clenups gets stuck because there are skbs with still hold nf_conn
references via their frag_list.
net.core.skb_defer_max=0 makes the hang disappear.
Eric Dumazet points out that skb_release_head_state() doesn't follow the
fraglist.
ip_defrag.sh can only reproduce this problem since
commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this
problem could happen with TCP as well if pmtu discovery is off.
The relevant problem path for udp is:
1. netns emits fragmented packets
2. nf_defrag_v6_hook reassembles them (in output hook)
3. reassembled skb is tracked (skb owns nf_conn reference)
4. ip6_output refragments
5. refragmented packets also own nf_conn reference (ip6_fragment
calls ip6_copy_metadata())
6. on input path, nf_defrag_v6_hook skips defragmentation: the
fragments already have skb->nf_conn attached
7. skbs are reassembled via ipv6_frag_rcv()
8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up
in pcpu freelist, but still has nf_conn reference.
Possible solutions:
1 let defrag engine drop nf_conn entry, OR
2 export kick_defer_list_purge() and call it from the conntrack
netns exit callback, OR
3 add skb_has_frag_list() check to skb_attempt_defer_free()
2 & 3 also solve ip_defrag.sh hang but share same drawback:
Such reassembled skbs, queued to socket, can prevent conntrack module
removal until userspace has consumed the packet. While both tcp and udp
stack do call nf_reset_ct() before placing skb on socket queue, that
function doesn't iterate frag_list skbs.
Therefore drop nf_conn entries when they are placed in defrag queue.
Keep the nf_conn entry of the first (offset 0) skb so that reassembled
skb retains nf_conn entry for sake of TX path.
Note that fixes tag is incorrect; it points to the commit introducing the
'ip_defrag.sh reproducible problem': no need to backport this patch to
every stable kernel.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths
The reference obtained by calling usb_get_dev() is not released in the
gpio_mpsse_probe() error paths. Fix that by using device managed helper
functions. Also remove the usb_put_dev() call in the disconnect function
since now it will be released automatically.
Published Jan 31, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: remove call_control in inactive contexts
If damon_call() is executed against a DAMON context that is not running,
the function returns error while keeping the damon_call_control object
linked to the context's call_controls list. Let's suppose the object is
deallocated after the damon_call(), and yet another damon_call() is
executed against the same context. The function tries to add the new
damon_call_control object to the call_controls list, which still has the
pointer to the previous damon_call_control object, which is deallocated.
As a result, use-after-free happens.
This can actually be triggered using the DAMON sysfs interface. It is not
easily exploitable since it requires the sysfs write permission and making
a definitely weird file writes, though. Please refer to the report for
more details about the issue reproduction steps.
Fix the issue by making two changes. Firstly, move the final
kdamond_call() for cancelling all existing damon_call() requests from
terminating DAMON context to be done before the ctx->kdamond reset. This
makes any code that sees NULL ctx->kdamond can safely assume the context
may not access damon_call() requests anymore. Secondly, let damon_call()
to cleanup the damon_call_control objects that were added to the
already-terminated DAMON context, before returning the error.
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
xhci: sideband: don't dereference freed ring when removing sideband endpoint
xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is
running and has a valid transfer ring.
Lianqin reported a crash during suspend/wake-up stress testing, and
found the cause to be dereferencing a non-existing transfer ring
'ep->ring' during xhci_sideband_remove_endpoint().
The endpoint and its ring may be in unknown state if this function
is called after xHCI was reinitialized in resume (lost power), or if
device is being re-enumerated, disconnected or endpoint already dropped.
Fix this by both removing unnecessary ring access, and by checking
ep->ring exists before dereferencing it. Also make sure endpoint is
running before attempting to stop it.
Remove the xhci_initialize_ring_info() call during sideband endpoint
removal as is it only initializes ring structure enqueue, dequeue and
cycle state values to their starting values without changing actual
hardware enqueue, dequeue and cycle state. Leaving them out of sync
is worse than leaving it as it is. The endpoint will get freed in after
this in most usecases.
If the (audio) class driver want's to reuse the endpoint after offload
then it is up to the class driver to ensure endpoint is properly set up.
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix KMS with 3D on HW version 10
HW version 10 does not have GB Surfaces so there is no backing buffer for
surface backed FBs. This would result in a nullptr dereference and crash
the driver causing a black screen.
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
block: zero non-PI portion of auto integrity buffer
The auto-generated integrity buffer for writes needs to be fully
initialized before being passed to the underlying block device,
otherwise the uninitialized memory can be read back by userspace or
anyone with physical access to the storage device. If protection
information is generated, that portion of the integrity buffer is
already initialized. The integrity data is also zeroed if PI generation
is disabled via sysfs or the PI tuple size is 0. However, this misses
the case where PI is generated and the PI tuple size is nonzero, but the
metadata size is larger than the PI tuple. In this case, the remainder
("opaque") of the metadata is left uninitialized.
Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the
metadata is larger than just the PI tuple.
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
ASoC: tlv320adcx140: fix null pointer
The "snd_soc_component" in "adcx140_priv" was only used once but never
set. It was only used for reaching "dev" which is already present in
"adcx140_priv".
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
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.
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback failure
mlx5e_netdev_change_profile can fail to attach a new profile and can
fail to rollback to old profile, in such case, we could end up with a
dangling netdev with a fully reset netdev_priv. A retry to change
profile, e.g. another attempt to call mlx5e_netdev_change_profile via
switchdev mode change, will crash trying to access the now NULL
priv->mdev.
This fix allows mlx5e_netdev_change_profile() to handle previous
failures and an empty priv, by not assuming priv is valid.
Pass netdev and mdev to all flows requiring
mlx5e_netdev_change_profile() and avoid passing priv.
In mlx5e_netdev_change_profile() check if current priv is valid, and if
not, just attach the new profile without trying to access the old one.
This fixes the following oops, when enabling switchdev mode for the 2nd
time after first time failure:
## Enabling switchdev mode first time:
mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
^^^^^^^^
mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
## retry: Enabling switchdev mode 2nd time:
mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload
BUG: kernel NULL pointer dereference, address: 0000000000000038
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:mlx5e_detach_netdev+0x3c/0x90
Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07
RSP: 0018:ffffc90000673890 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000
RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000
R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000
R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000
FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0
Call Trace:
<TASK>
mlx5e_netdev_change_profile+0x45/0xb0
mlx5e_vport_rep_load+0x27b/0x2d0
mlx5_esw_offloads_rep_load+0x72/0xf0
esw_offloads_enable+0x5d0/0x970
mlx5_eswitch_enable_locked+0x349/0x430
? is_mp_supported+0x57/0xb0
mlx5_devlink_eswitch_mode_set+0x26b/0x430
devlink_nl_eswitch_set_doit+0x6f/0xf0
genl_family_rcv_msg_doit+0xe8/0x140
genl_rcv_msg+0x18b/0x290
? __pfx_devlink_nl_pre_doit+0x10/0x10
? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10
? __pfx_devlink_nl_post_doit+0x10/0x10
? __pfx_genl_rcv_msg+0x10/0x10
netlink_rcv_skb+0x52/0x100
genl_rcv+0x28/0x40
netlink_unicast+0x282/0x3e0
? __alloc_skb+0xd6/0x190
netlink_sendmsg+0x1f7/0x430
__sys_sendto+0x213/0x220
? __sys_recvmsg+0x6a/0xd0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x50/0x1f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fdfb8495047
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv
mlx5e_priv is an unstable structure that can be memset(0) if profile
attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to
reference the netdev and mdev associated with that struct. Instead,
store netdev directly into mlx5e_dev and get mdev from the containing
mlx5_adev aux device structure.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due
to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev
Error: mlx5_core: Failed setting eswitch to offloads.
dmesg:
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000520
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:mlx5e_remove+0x68/0x130
RSP: 0018:ffffc900034838f0 EFLAGS: 00010246
RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10
R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0
R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400
FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0
Call Trace:
<TASK>
device_release_driver_internal+0x19c/0x200
bus_remove_device+0xc6/0x130
device_del+0x160/0x3d0
? devl_param_driverinit_value_get+0x2d/0x90
mlx5_detach_device+0x89/0xe0
mlx5_unload_one_devl_locked+0x3a/0x70
mlx5_devlink_reload_down+0xc8/0x220
devlink_reload+0x7d/0x260
devlink_nl_reload_doit+0x45b/0x5a0
genl_family_rcv_msg_doit+0xe8/0x140
Published Jan 25, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
ublk: fix use-after-free in ublk_partition_scan_work
A race condition exists between the async partition scan work and device
teardown that can lead to a use-after-free of ub->ub_disk:
1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()
2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:
- del_gendisk(ub->ub_disk)
- ublk_detach_disk() sets ub->ub_disk = NULL
- put_disk() which may free the disk
3. The worker ublk_partition_scan_work() then dereferences ub->ub_disk
leading to UAF
Fix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold
a reference to the disk during the partition scan. The spinlock in
ublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker
either gets a valid reference or sees NULL and exits early.
Also change flush_work() to cancel_work_sync() to avoid running the
partition scan work unnecessarily when the disk is already detached.
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: Fix RSS LUT NULL ptr issue after soft reset
During soft reset, the RSS LUT is freed and not restored unless the
interface is up. If an ethtool command that accesses the rss lut is
attempted immediately after reset, it will result in NULL ptr
dereference. Also, there is no need to reset the rss lut if the soft reset
does not involve queue count change.
After soft reset, set the RSS LUT to default values based on the updated
queue count only if the reset was a result of a queue count change and
the LUT was not configured by the user. In all other cases, don't touch
the LUT.
Steps to reproduce:
** Bring the interface down (if up)
ifconfig eth1 down
** update the queue count (eg., 27->20)
ethtool -L eth1 combined 20
** display the RSS LUT
ethtool -x eth1
[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000
[82375.558373] #PF: supervisor read access in kernel mode
[82375.558391] #PF: error_code(0x0000) - not-present page
[82375.558408] PGD 0 P4D 0
[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI
<snip>
[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf]
[82375.558786] Call Trace:
[82375.558793] <TASK>
[82375.558804] rss_prepare.isra.0+0x187/0x2a0
[82375.558827] rss_prepare_data+0x3a/0x50
[82375.558845] ethnl_default_doit+0x13d/0x3e0
[82375.558863] genl_family_rcv_msg_doit+0x11f/0x180
[82375.558886] genl_rcv_msg+0x1ad/0x2b0
[82375.558902] ? __pfx_ethnl_default_doit+0x10/0x10
[82375.558920] ? __pfx_genl_rcv_msg+0x10/0x10
[82375.558937] netlink_rcv_skb+0x58/0x100
[82375.558957] genl_rcv+0x2c/0x50
[82375.558971] netlink_unicast+0x289/0x3e0
[82375.558988] netlink_sendmsg+0x215/0x440
[82375.559005] __sys_sendto+0x234/0x240
[82375.559555] __x64_sys_sendto+0x28/0x30
[82375.560068] x64_sys_call+0x1909/0x1da0
[82375.560576] do_syscall_64+0x7a/0xfa0
[82375.561076] ? clear_bhb_loop+0x60/0xb0
[82375.561567] entry_SYSCALL_64_after_hwframe+0x76/0x7e
<snip>
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
nfsd: check that server is running in unlock_filesystem
If we are trying to unlock the filesystem via an administrative
interface and nfsd isn't running, it crashes the server. This
happens currently because nfsd4_revoke_states() access state
structures (eg., conf_id_hashtbl) that has been freed as a part
of the server shutdown.
[ 59.465072] Call trace:
[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)
[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]
[ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]
[ 59.466780] vfs_write+0x1f0/0x938
[ 59.467088] ksys_write+0xfc/0x1f8
[ 59.467395] __arm64_sys_write+0x74/0xb8
[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8
[ 59.468177] do_el0_svc+0x154/0x1d8
[ 59.468489] el0_svc+0x40/0xe0
[ 59.468767] el0t_64_sync_handler+0xa0/0xe8
[ 59.469138] el0t_64_sync+0x1ac/0x1b0
Ensure this can't happen by taking the nfsd_mutex and checking that
the server is still up, and then holding the mutex across the call to
nfsd4_revoke_states().
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: avoid dereferencing ERR_PTR in tcf_idrinfo_destroy
syzbot reported a crash in tc_act_in_hw() during netns teardown where
tcf_idrinfo_destroy() passed an ERR_PTR(-EBUSY) value as a tc_action
pointer, leading to an invalid dereference.
Guard against ERR_PTR entries when iterating the action IDR so teardown
does not call tc_act_in_hw() on an error pointer.
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix race condition for gdev->srcu
If two drivers were calling gpiochip_add_data_with_key(), one may be
traversing the srcu-protected list in gpio_name_to_desc(), meanwhile
other has just added its gdev in gpiodev_add_to_list_unlocked().
This creates a non-mutexed and non-protected timeframe, when one
instance is dereferencing and using &gdev->srcu, before the other
has initialized it, resulting in crash:
[ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000
[ 4.943396] Mem abort info:
[ 4.943400] ESR = 0x0000000096000005
[ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits
[ 4.943407] SET = 0, FnV = 0
[ 4.943410] EA = 0, S1PTW = 0
[ 4.943413] FSC = 0x05: level 1 translation fault
[ 4.943416] Data abort info:
[ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000
[ 4.961449] [ffff800272bcc000] pgd=0000000000000000
[ 4.969203] , p4d=1000000039739003
[ 4.979730] , pud=0000000000000000
[ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset"
[ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
...
[ 5.121359] pc : __srcu_read_lock+0x44/0x98
[ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0
[ 5.153671] sp : ffff8000833bb430
[ 5.298440]
[ 5.298443] Call trace:
[ 5.298445] __srcu_read_lock+0x44/0x98
[ 5.309484] gpio_name_to_desc+0x60/0x1a0
[ 5.320692] gpiochip_add_data_with_key+0x488/0xf00
5.946419] ---[ end trace 0000000000000000 ]---
Move initialization code for gdev fields before it is added to
gpio_devices, with adjacent initialization code.
Adjust goto statements to reflect modified order of operations
[Bartosz: fixed a build issue, removed stray newline]
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: Fix RSS LUT NULL pointer crash on early ethtool operations
The RSS LUT is not initialized until the interface comes up, causing
the following NULL pointer crash when ethtool operations like rxhash on/off
are performed before the interface is brought up for the first time.
Move RSS LUT initialization from ndo_open to vport creation to ensure LUT
is always available. This enables RSS configuration via ethtool before
bringing the interface up. Simplify LUT management by maintaining all
changes in the driver's soft copy and programming zeros to the indirection
table when rxhash is disabled. Defer HW programming until the interface
comes up if it is down during rxhash and LUT configuration changes.
Steps to reproduce:
** Load idpf driver; interfaces will be created
modprobe idpf
** Before bringing the interfaces up, turn rxhash off
ethtool -K eth2 rxhash off
[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000
[89408.371908] #PF: supervisor read access in kernel mode
[89408.371924] #PF: error_code(0x0000) - not-present page
[89408.371940] PGD 0 P4D 0
[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI
<snip>
[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130
[89408.372310] Call Trace:
[89408.372317] <TASK>
[89408.372326] ? idpf_set_features+0xfc/0x180 [idpf]
[89408.372363] __netdev_update_features+0x295/0xde0
[89408.372384] ethnl_set_features+0x15e/0x460
[89408.372406] genl_family_rcv_msg_doit+0x11f/0x180
[89408.372429] genl_rcv_msg+0x1ad/0x2b0
[89408.372446] ? __pfx_ethnl_set_features+0x10/0x10
[89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10
[89408.372482] netlink_rcv_skb+0x58/0x100
[89408.372502] genl_rcv+0x2c/0x50
[89408.372516] netlink_unicast+0x289/0x3e0
[89408.372533] netlink_sendmsg+0x215/0x440
[89408.372551] __sys_sendto+0x234/0x240
[89408.372571] __x64_sys_sendto+0x28/0x30
[89408.372585] x64_sys_call+0x1909/0x1da0
[89408.372604] do_syscall_64+0x7a/0xfa0
[89408.373140] ? clear_bhb_loop+0x60/0xb0
[89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[89408.378887] </TASK>
<snip>
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
net: do not write to msg_get_inq in callee
NULL pointer dereference fix.
msg_get_inq is an input field from caller to callee. Don't set it in
the callee, as the caller may not clear it on struct reuse.
This is a kernel-internal variant of msghdr only, and the only user
does reinitialize the field. So this is not critical for that reason.
But it is more robust to avoid the write, and slightly simpler code.
And it fixes a bug, see below.
Callers set msg_get_inq to request the input queue length to be
returned in msg_inq. This is equivalent to but independent from the
SO_INQ request to return that same info as a cmsg (tp->recvmsg_inq).
To reduce branching in the hot path the second also sets the msg_inq.
That is WAI.
This is a fix to commit 4d1442979e4a ("af_unix: don't post cmsg for
SO_INQ unless explicitly asked for"), which fixed the inverse.
Also avoid NULL pointer dereference in unix_stream_read_generic if
state->msg is NULL and msg->msg_get_inq is written. A NULL state->msg
can happen when splicing as of commit 2b514574f7e8 ("net: af_unix:
implement splice for stream af_unix sockets").
Also collapse two branches using a bitwise or.
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
idpf: detach and close netdevs while handling a reset
Protect the reset path from callbacks by setting the netdevs to detached
state and close any netdevs in UP state until the reset handling has
completed. During a reset, the driver will de-allocate resources for the
vport, and there is no guarantee that those will recover, which is why the
existing vport_ctrl_lock does not provide sufficient protection.
idpf_detach_and_close() is called right before reset handling. If the
reset handling succeeds, the netdevs state is recovered via call to
idpf_attach_and_open(). If the reset handling fails the netdevs remain
down. The detach/down calls are protected with RTNL lock to avoid racing
with callbacks. On the recovery side the attach can be done without
holding the RTNL lock as there are no callbacks expected at that point,
due to detach/close always being done first in that flow.
The previous logic restoring the netdevs state based on the
IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence
the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is
still being used to restore the state of the netdevs following the reset,
but has no use outside of the reset handling flow.
idpf_init_hard_reset() is converted to void, since it was used as such and
there is no error handling being done based on its return value.
Before this change, invoking hard and soft resets simultaneously will
cause the driver to lose the vport state:
ip -br a
<inf> UP
echo 1 > /sys/class/net/ens801f0/device/reset& \
ethtool -L ens801f0 combined 8
ip -br a
<inf> DOWN
ip link set <inf> up
ip -br a
<inf> DOWN
Also in case of a failure in the reset path, the netdev is left
exposed to external callbacks, while vport resources are not
initialized, leading to a crash on subsequent ifup/down:
[408471.398966] idpf 0000:83:00.0: HW reset detected
[408471.411744] idpf 0000:83:00.0: Device HW Reset initiated
[408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2
[408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078
[408508.126112] #PF: supervisor read access in kernel mode
[408508.126687] #PF: error_code(0x0000) - not-present page
[408508.127256] PGD 2aae2f067 P4D 0
[408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI
...
[408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]
...
[408508.139193] Call Trace:
[408508.139637] <TASK>
[408508.140077] __dev_close_many+0xbb/0x260
[408508.140533] __dev_change_flags+0x1cf/0x280
[408508.140987] netif_change_flags+0x26/0x70
[408508.141434] dev_change_flags+0x3d/0xb0
[408508.141878] devinet_ioctl+0x460/0x890
[408508.142321] inet_ioctl+0x18e/0x1d0
[408508.142762] ? _copy_to_user+0x22/0x70
[408508.143207] sock_do_ioctl+0x3d/0xe0
[408508.143652] sock_ioctl+0x10e/0x330
[408508.144091] ? find_held_lock+0x2b/0x80
[408508.144537] __x64_sys_ioctl+0x96/0xe0
[408508.144979] do_syscall_64+0x79/0x3d0
[408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[408508.145860] RIP: 0033:0x7f3e0bb4caff
Published Jan 23, 2026 · Updated May 11, 2026
Unknown · CVSS Not scored
In the Linux kernel, the following vulnerability has been resolved:
wifi: avoid kernel-infoleak from struct iw_point
struct iw_point has a 32bit hole on 64bit arches.
struct iw_point {
void __user *pointer; /* Pointer to the data (in user space) */
__u16 length; /* number of fields or size in bytes */
__u16 flags; /* Optional params */
};
Make sure to zero the structure to avoid disclosing 32bits of kernel data
to user space.
Published Jan 23, 2026 · Updated May 11, 2026
Medium · CVSS 4.3
Missing Authorization vulnerability in Campaign Monitor Campaign Monitor for WordPress allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects Campaign Monitor for WordPress: from n/a through 2.9.1.
Published Jan 8, 2026 · Updated May 11, 2026
Medium · CVSS 5.3
Improper Control of Generation of Code ('Code Injection') vulnerability in liuyueyi quick-media (plugins/svg-plugin/batik-codec-fix/src/main/java/org/apache/batik/ext/awt/image/codec/png modules). This vulnerability is associated with program files PNGImageEncoder.Java.
This issue affects quick-media: before v1.0.
Published Jan 27, 2026 · Updated May 6, 2026
Medium · CVSS 5.3
Improper Verification of Cryptographic Signature vulnerability in liuyueyi quick-media (plugins/svg-plugin/batik-codec-fix/src/main/java/org/apache/batik/ext/awt/image/codec/util modules). This vulnerability is associated with program files SeekableOutputStream.Java.
This issue affects quick-media: before v1.0.
Published Jan 27, 2026 · Updated May 6, 2026
Medium · CVSS 6.6
Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. The `ig` binary provides a subcommand for image building, used to generate custom gadget OCI images. A part of this functionality is implemented in the file `inspektor-gadget/cmd/common/image/build.go`. The `Makefile.build` file is the Makefile template employed during the building process. This file includes user-controlled data in an unsafe fashion, specifically some parameters are embedded without an adequate escaping in the commands inside the Makefile. Prior to version 0.48.1, this implementation is vulnerable to command injection: an attacker able to control values in the `buildOptions` structure would be able to execute arbitrary commands during the building process. An attacker able to exploit this vulnerability would be able to execute arbitrary command on the Linux host where the `ig` command is launched, if images are built with the `--local` flag or on the build container invoked by `ig`, if the `--local` flag is not provided. The `buildOptions` structure is extracted from the YAML gadget manifest passed to the `ig image build` command. Therefore, the attacker would need a way to control either the full `build.yml` file passed to the `ig image build` command, or one of its options. Typically, this could happen in a CI/CD scenario that builds untrusted gadgets to verify correctness. Version 0.51.1 fixes the issue.
Published Jan 29, 2026 · Updated Apr 30, 2026
Critical · CVSS 9.8
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Salesforce Marketing Cloud Engagement (CloudPagesUrl module) allows Web Services Protocol Manipulation. This issue affects Marketing Cloud Engagement: before January 21st, 2026.
Published Jan 24, 2026 · Updated Apr 29, 2026
Critical · CVSS 9.8
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Salesforce Marketing Cloud Engagement (MicrositeUrl module) allows Web Services Protocol Manipulation. This issue affects Marketing Cloud Engagement: before January 21st, 2026.
Published Jan 24, 2026 · Updated Apr 29, 2026
Critical · CVSS 9.8
Use of a Broken or Risky Cryptographic Algorithm vulnerability in Salesforce Marketing Cloud Engagement (CloudPages, Forward to a Friend, Profile Center, Subscription Center, Unsub Center, View As Webpage modules) allows Web Services Protocol Manipulation. This issue affects Marketing Cloud Engagement: before January 21st, 2026.
Published Jan 24, 2026 · Updated Apr 29, 2026
Critical · CVSS 9.8
Hard-coded Cryptographic Key vulnerability in Salesforce Marketing Cloud Engagement (CloudPages, Forward to a Friend, Profile Center, Subscription Center, Unsub Center, View As Webpage modules) allows Web Services Protocol Manipulation. This issue affects Marketing Cloud Engagement: before January 21st, 2026.
Published Jan 24, 2026 · Updated Apr 29, 2026
High · CVSS 7.1
The HTTP parser of Tapo C210 v3, C220 v1 and C520WS v2 cameras improperly handles requests containing an excessively long URL path. An invalid‑URL error path continues into cleanup code that assumes allocated buffers exist, leading to a crash and service restart. An unauthenticated attacker can force repeated service crashes or device reboots, causing denial of service.
Published Jan 27, 2026 · Updated Apr 29, 2026
Medium · CVSS 5.3
Missing Authorization vulnerability in Re Gallery allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Re Gallery: from n/a through 1.18.9.
Published Jan 8, 2026 · Updated Apr 29, 2026
