Skip to content

Commit 2d992ea

Browse files
Advisory Database Sync
1 parent 9c51245 commit 2d992ea

77 files changed

Lines changed: 796 additions & 262 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

advisories/unreviewed/2026/02/GHSA-25gw-4v5m-94pp/GHSA-25gw-4v5m-94pp.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-25gw-4v5m-94pp",
4-
"modified": "2026-02-06T18:30:30Z",
4+
"modified": "2026-03-18T15:30:39Z",
55
"published": "2026-02-04T18:30:43Z",
66
"aliases": [
77
"CVE-2026-23078"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Fix buffer overflow in config retrieval\n\nThe scarlett2_usb_get_config() function has a logic error in the\nendianness conversion code that can cause buffer overflows when\ncount > 1.\n\nThe code checks `if (size == 2)` where `size` is the total buffer size in\nbytes, then loops `count` times treating each element as u16 (2 bytes).\nThis causes the loop to access `count * 2` bytes when the buffer only\nhas `size` bytes allocated.\n\nFix by checking the element size (config_item->size) instead of the\ntotal buffer size. This ensures the endianness conversion matches the\nactual element type.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -40,8 +45,10 @@
4045
}
4146
],
4247
"database_specific": {
43-
"cwe_ids": [],
44-
"severity": null,
48+
"cwe_ids": [
49+
"CWE-787"
50+
],
51+
"severity": "HIGH",
4552
"github_reviewed": false,
4653
"github_reviewed_at": null,
4754
"nvd_published_at": "2026-02-04T17:16:18Z"

advisories/unreviewed/2026/02/GHSA-2m65-7fpj-78p9/GHSA-2m65-7fpj-78p9.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-2m65-7fpj-78p9",
4-
"modified": "2026-02-14T18:30:16Z",
4+
"modified": "2026-03-18T15:30:41Z",
55
"published": "2026-02-14T18:30:16Z",
66
"aliases": [
77
"CVE-2026-23186"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()\n\nThe acpi_power_meter driver's .notify() callback function,\nacpi_power_meter_notify(), calls hwmon_device_unregister() under a lock\nthat is also acquired by callbacks in sysfs attributes of the device\nbeing unregistered which is prone to deadlocks between sysfs access and\ndevice removal.\n\nAddress this by moving the hwmon device removal in\nacpi_power_meter_notify() outside the lock in question, but notice\nthat doing it alone is not sufficient because two concurrent\nMETER_NOTIFY_CONFIG notifications may be attempting to remove the\nsame device at the same time. To prevent that from happening, add a\nnew lock serializing the execution of the switch () statement in\nacpi_power_meter_notify(). For simplicity, it is a static mutex\nwhich should not be a problem from the performance perspective.\n\nThe new lock also allows the hwmon_device_register_with_info()\nin acpi_power_meter_notify() to be called outside the inner lock\nbecause it prevents the other notifications handled by that function\nfrom manipulating the \"resource\" object while the hwmon device based\non it is being registered. The sending of ACPI netlink messages from\nacpi_power_meter_notify() is serialized by the new lock too which\ngenerally helps to ensure that the order of handling firmware\nnotifications is the same as the order of sending netlink messages\nrelated to them.\n\nIn addition, notice that hwmon_device_register_with_info() may fail\nin which case resource->hwmon_dev will become an error pointer,\nso add checks to avoid attempting to unregister the hwmon device\npointer to by it in that case to acpi_power_meter_notify() and\nacpi_power_meter_remove().",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -24,8 +29,10 @@
2429
}
2530
],
2631
"database_specific": {
27-
"cwe_ids": [],
28-
"severity": null,
32+
"cwe_ids": [
33+
"CWE-667"
34+
],
35+
"severity": "MODERATE",
2936
"github_reviewed": false,
3037
"github_reviewed_at": null,
3138
"nvd_published_at": "2026-02-14T17:15:56Z"

advisories/unreviewed/2026/02/GHSA-2wj2-8hhp-h6hm/GHSA-2wj2-8hhp-h6hm.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-2wj2-8hhp-h6hm",
4-
"modified": "2026-02-14T15:32:19Z",
4+
"modified": "2026-03-18T15:30:40Z",
55
"published": "2026-02-14T15:32:19Z",
66
"aliases": [
77
"CVE-2026-23126"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix a race issue related to the operation on bpf_bound_progs list\n\nThe netdevsim driver lacks a protection mechanism for operations on the\nbpf_bound_progs list. When the nsim_bpf_create_prog() performs\nlist_add_tail, it is possible that nsim_bpf_destroy_prog() is\nsimultaneously performs list_del. Concurrent operations on the list may\nlead to list corruption and trigger a kernel crash as follows:\n\n[ 417.290971] kernel BUG at lib/list_debug.c:62!\n[ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1\n[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 417.291007] Workqueue: events bpf_prog_free_deferred\n[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0\n[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8\n[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246\n[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000\n[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180\n[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003\n[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20\n[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000\n[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000\n[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0\n[ 417.291088] PKRU: 55555554\n[ 417.291091] Call Trace:\n[ 417.291096] <TASK>\n[ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]\n[ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80\n[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0\n[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0\n[ 417.291178] process_one_work+0x18a/0x3a0\n[ 417.291188] worker_thread+0x27b/0x3a0\n[ 417.291197] ? __pfx_worker_thread+0x10/0x10\n[ 417.291207] kthread+0xe5/0x120\n[ 417.291214] ? __pfx_kthread+0x10/0x10\n[ 417.291221] ret_from_fork+0x31/0x50\n[ 417.291230] ? __pfx_kthread+0x10/0x10\n[ 417.291236] ret_from_fork_asm+0x1a/0x30\n[ 417.291246] </TASK>\n\nAdd a mutex lock, to prevent simultaneous addition and deletion operations\non the list.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -36,8 +41,10 @@
3641
}
3742
],
3843
"database_specific": {
39-
"cwe_ids": [],
40-
"severity": null,
44+
"cwe_ids": [
45+
"CWE-362"
46+
],
47+
"severity": "MODERATE",
4148
"github_reviewed": false,
4249
"github_reviewed_at": null,
4350
"nvd_published_at": "2026-02-14T15:16:07Z"

advisories/unreviewed/2026/02/GHSA-398f-64gc-qxqm/GHSA-398f-64gc-qxqm.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-398f-64gc-qxqm",
4-
"modified": "2026-02-14T18:30:15Z",
4+
"modified": "2026-03-18T15:30:40Z",
55
"published": "2026-02-14T18:30:15Z",
66
"aliases": [
77
"CVE-2026-23159"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: sched: Fix perf crash with new is_user_task() helper\n\nIn order to do a user space stacktrace the current task needs to be a user\ntask that has executed in user space. It use to be possible to test if a\ntask is a user task or not by simply checking the task_struct mm field. If\nit was non NULL, it was a user task and if not it was a kernel task.\n\nBut things have changed over time, and some kernel tasks now have their\nown mm field.\n\nAn idea was made to instead test PF_KTHREAD and two functions were used to\nwrap this check in case it became more complex to test if a task was a\nuser task or not[1]. But this was rejected and the C code simply checked\nthe PF_KTHREAD directly.\n\nIt was later found that not all kernel threads set PF_KTHREAD. The io-uring\nhelpers instead set PF_USER_WORKER and this needed to be added as well.\n\nBut checking the flags is still not enough. There's a very small window\nwhen a task exits that it frees its mm field and it is set back to NULL.\nIf perf were to trigger at this moment, the flags test would say its a\nuser space task but when perf would read the mm field it would crash with\nat NULL pointer dereference.\n\nNow there are flags that can be used to test if a task is exiting, but\nthey are set in areas that perf may still want to profile the user space\ntask (to see where it exited). The only real test is to check both the\nflags and the mm field.\n\nInstead of making this modification in every location, create a new\nis_user_task() helper function that does all the tests needed to know if\nit is safe to read the user space memory or not.\n\n[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -32,8 +37,10 @@
3237
}
3338
],
3439
"database_specific": {
35-
"cwe_ids": [],
36-
"severity": null,
40+
"cwe_ids": [
41+
"CWE-476"
42+
],
43+
"severity": "MODERATE",
3744
"github_reviewed": false,
3845
"github_reviewed_at": null,
3946
"nvd_published_at": "2026-02-14T16:15:56Z"

advisories/unreviewed/2026/02/GHSA-3gqm-m375-7mp2/GHSA-3gqm-m375-7mp2.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-3gqm-m375-7mp2",
4-
"modified": "2026-02-06T18:30:31Z",
4+
"modified": "2026-03-18T15:30:39Z",
55
"published": "2026-02-04T18:30:44Z",
66
"aliases": [
77
"CVE-2026-23097"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmigrate: correct lock ordering for hugetlb file folios\n\nSyzbot has found a deadlock (analyzed by Lance Yang):\n\n1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).\n2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire\nfolio_lock.\n\nmigrate_pages()\n -> migrate_hugetlbs()\n -> unmap_and_move_huge_page() <- Takes folio_lock!\n -> remove_migration_ptes()\n -> __rmap_walk_file()\n -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!\n\nhugetlbfs_fallocate()\n -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)!\n -> hugetlbfs_zero_partial_page()\n -> filemap_lock_hugetlb_folio()\n -> filemap_lock_folio()\n -> __filemap_get_folio <- Waits for folio_lock!\n\nThe migration path is the one taking locks in the wrong order according to\nthe documentation at the top of mm/rmap.c. So expand the scope of the\nexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.\n\nThis is (mostly) how it used to be after commit c0d0381ade79. That was\nremoved by 336bf30eb765 for both file & anon hugetlb pages when it should\nonly have been removed for anon hugetlb pages.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -45,7 +50,7 @@
4550
],
4651
"database_specific": {
4752
"cwe_ids": [],
48-
"severity": null,
53+
"severity": "MODERATE",
4954
"github_reviewed": false,
5055
"github_reviewed_at": null,
5156
"nvd_published_at": "2026-02-04T17:16:20Z"

advisories/unreviewed/2026/02/GHSA-3jpp-f2wm-pcvv/GHSA-3jpp-f2wm-pcvv.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-3jpp-f2wm-pcvv",
4-
"modified": "2026-02-14T18:30:16Z",
4+
"modified": "2026-03-18T15:30:41Z",
55
"published": "2026-02-14T18:30:16Z",
66
"aliases": [
77
"CVE-2026-23185"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mld: cancel mlo_scan_start_wk\n\nmlo_scan_start_wk is not canceled on disconnection. In fact, it is not\ncanceled anywhere except in the restart cleanup, where we don't really\nhave to.\n\nThis can cause an init-after-queue issue: if, for example, the work was\nqueued and then drv_change_interface got executed.\n\nThis can also cause use-after-free: if the work is executed after the\nvif is freed.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -24,8 +29,10 @@
2429
}
2530
],
2631
"database_specific": {
27-
"cwe_ids": [],
28-
"severity": null,
32+
"cwe_ids": [
33+
"CWE-416"
34+
],
35+
"severity": "HIGH",
2936
"github_reviewed": false,
3037
"github_reviewed_at": null,
3138
"nvd_published_at": "2026-02-14T17:15:56Z"

advisories/unreviewed/2026/02/GHSA-3w5h-8286-m3qw/GHSA-3w5h-8286-m3qw.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-3w5h-8286-m3qw",
4-
"modified": "2026-02-14T15:32:18Z",
4+
"modified": "2026-03-18T15:30:40Z",
55
"published": "2026-02-14T15:32:18Z",
66
"aliases": [
77
"CVE-2026-23120"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: avoid one data-race in l2tp_tunnel_del_work()\n\nWe should read sk->sk_socket only when dealing with kernel sockets.\n\nsyzbot reported the following data-race:\n\nBUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release\n\nwrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:\n sk_set_socket include/net/sock.h:2092 [inline]\n sock_orphan include/net/sock.h:2118 [inline]\n sk_common_release+0xae/0x230 net/core/sock.c:4003\n udp_lib_close+0x15/0x20 include/net/udp.h:325\n inet_release+0xce/0xf0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:662 [inline]\n sock_close+0x6b/0x150 net/socket.c:1455\n __fput+0x29b/0x650 fs/file_table.c:468\n ____fput+0x1c/0x30 fs/file_table.c:496\n task_work_run+0x131/0x1a0 kernel/task_work.c:233\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]\n exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:\n l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340\n worker_thread+0x582/0x770 kernel/workqueue.c:3421\n kthread+0x489/0x510 kernel/kthread.c:463\n ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n\nvalue changed: 0xffff88811b818000 -> 0x0000000000000000",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -45,7 +50,7 @@
4550
],
4651
"database_specific": {
4752
"cwe_ids": [],
48-
"severity": null,
53+
"severity": "MODERATE",
4954
"github_reviewed": false,
5055
"github_reviewed_at": null,
5156
"nvd_published_at": "2026-02-14T15:16:07Z"

advisories/unreviewed/2026/02/GHSA-3x2r-29rp-vh66/GHSA-3x2r-29rp-vh66.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-3x2r-29rp-vh66",
4-
"modified": "2026-02-14T18:30:15Z",
4+
"modified": "2026-03-18T15:30:40Z",
55
"published": "2026-02-14T18:30:15Z",
66
"aliases": [
77
"CVE-2026-23163"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove\n\nOn APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and\nih2 interrupt ring buffers are not initialized. This is by design, as\nthese secondary IH rings are only available on discrete GPUs. See\nvega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when\nAMD_IS_APU is set.\n\nHowever, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to\nget the timestamp of the last interrupt entry. When retry faults are\nenabled on APUs (noretry=0), this function is called from the SVM page\nfault recovery path, resulting in a NULL pointer dereference when\namdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].\n\nThe crash manifests as:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000004\n RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]\n Call Trace:\n amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]\n svm_range_restore_pages+0xae5/0x11c0 [amdgpu]\n amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]\n gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]\n amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]\n amdgpu_ih_process+0x84/0x100 [amdgpu]\n\nThis issue was exposed by commit 1446226d32a4 (\"drm/amdgpu: Remove GC HW\nIP 9.3.0 from noretry=1\") which changed the default for Renoir APU from\nnoretry=1 to noretry=0, enabling retry fault handling and thus\nexercising the buggy code path.\n\nFix this by adding a check for ih1.ring_size before attempting to use\nit. Also restore the soft_ih support from commit dd299441654f (\"drm/amdgpu:\nRework retry fault removal\"). This is needed if the hardware doesn't\nsupport secondary HW IH rings.\n\nv2: additional updates (Alex)\n\n(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -32,8 +37,10 @@
3237
}
3338
],
3439
"database_specific": {
35-
"cwe_ids": [],
36-
"severity": null,
40+
"cwe_ids": [
41+
"CWE-476"
42+
],
43+
"severity": "MODERATE",
3744
"github_reviewed": false,
3845
"github_reviewed_at": null,
3946
"nvd_published_at": "2026-02-14T16:15:56Z"

advisories/unreviewed/2026/02/GHSA-44pj-mggw-c3m7/GHSA-44pj-mggw-c3m7.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-44pj-mggw-c3m7",
4-
"modified": "2026-02-14T15:32:18Z",
4+
"modified": "2026-03-18T15:30:40Z",
55
"published": "2026-02-14T15:32:18Z",
66
"aliases": [
77
"CVE-2026-23116"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu\n\nFor i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset\nand clock enable bits, but is ungated and reset together with the VPUs.\nSo we can't reset G1 or G2 separately, it may led to the system hang.\nRemove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.\nLet imx8mq_vpu_power_notifier() do really vpu reset.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -37,7 +42,7 @@
3742
],
3843
"database_specific": {
3944
"cwe_ids": [],
40-
"severity": null,
45+
"severity": "MODERATE",
4146
"github_reviewed": false,
4247
"github_reviewed_at": null,
4348
"nvd_published_at": "2026-02-14T15:16:06Z"

0 commit comments

Comments
 (0)