Publish Advisories

GHSA-9973-9x4h-pfgx
GHSA-459r-g93g-c5wc
GHSA-6v6p-g835-47x6
GHSA-9rxx-pq63-85w7
GHSA-pm7p-wjq9-6m43
GHSA-rcx5-mm72-w6xv
GHSA-vc22-mx78-4mgj
GHSA-29x9-4344-px4h
GHSA-qj3c-cr7p-g92q

Author: advisory-database[bot]

advisories/unreviewed/2025/03/GHSA-9973-9x4h-pfgx/GHSA-9973-9x4h-pfgx.json

@@ -1,13 +1,17 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9973-9x4h-pfgx",
-  "modified": "2025-03-07T18:31:06Z",
+  "modified": "2026-01-22T18:50:52Z",
   "published": "2025-03-07T18:31:05Z",
   "aliases": [
     "CVE-2024-50394"
   ],
   "details": "An improper certificate validation vulnerability has been reported to affect Helpdesk. If exploited, the vulnerability could allow remote attackers to compromise the security of the system.\n\nWe have already fixed the vulnerability in the following version:\nHelpdesk 3.3.3 and later",
   "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
+    },
     {
       "type": "CVSS_V4",
       "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"

advisories/unreviewed/2025/08/GHSA-459r-g93g-c5wc/GHSA-459r-g93g-c5wc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-459r-g93g-c5wc",
-  "modified": "2025-11-03T18:31:33Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-08-16T12:30:33Z",
   "aliases": [
     "CVE-2025-38540"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras\n\nThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)\nreport a HID sensor interface that is not actually implemented.\nAttempting to access this non-functional sensor via iio_info causes\nsystem hangs as runtime PM tries to wake up an unresponsive sensor.\n\nAdd these 2 devices to the HID ignore list since the sensor interface is\nnon-functional by design and should not be exposed to userspace.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -57,7 +62,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-16T12:15:29Z"

advisories/unreviewed/2025/08/GHSA-6v6p-g835-47x6/GHSA-6v6p-g835-47x6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6v6p-g835-47x6",
-  "modified": "2025-12-23T18:30:20Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-08-22T18:31:23Z",
   "aliases": [
     "CVE-2025-38670"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()\n\n`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change\nto different stacks along with the Shadow Call Stack if it is enabled.\nThose two stack changes cannot be done atomically and both functions\ncan be interrupted by SErrors or Debug Exceptions which, though unlikely,\nis very much broken : if interrupted, we can end up with mismatched stacks\nand Shadow Call Stack leading to clobbered stacks.\n\nIn `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,\nbut x18 stills points to the old task's SCS. When the interrupt handler\ntries to save the task's SCS pointer, it will save the old task\nSCS pointer (x18) into the new task struct (pointed to by SP_EL0),\nclobbering it.\n\nIn `call_on_irq_stack()`, it can happen when switching from the task stack\nto the IRQ stack and when switching back. In both cases, we can be\ninterrupted when the SCS pointer points to the IRQ SCS, but SP points to\nthe task stack. The nested interrupt handler pushes its return addresses\non the IRQ SCS. It then detects that SP points to the task stack,\ncalls `call_on_irq_stack()` and clobbers the task SCS pointer with\nthe IRQ SCS pointer, which it will also use !\n\nThis leads to tasks returning to addresses on the wrong SCS,\nor even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK\nor FPAC if enabled.\n\nThis is possible on a default config, but unlikely.\nHowever, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and\ninstead the GIC is responsible for filtering what interrupts the CPU\nshould receive based on priority.\nGiven the goal of emulating NMIs, pseudo-NMIs can be received by the CPU\neven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*\nfrequently depending on the system configuration and workload, leading\nto unpredictable kernel panics.\n\nCompletely mask DAIF in `cpu_switch_to()` and restore it when returning.\nDo the same in `call_on_irq_stack()`, but restore and mask around\nthe branch.\nMask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency\nof behaviour between all configurations.\n\nIntroduce and use an assembly macro for saving and masking DAIF,\nas the existing one saves but only masks IF.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -48,8 +53,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-668"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-22T16:15:42Z"

advisories/unreviewed/2025/08/GHSA-9rxx-pq63-85w7/GHSA-9rxx-pq63-85w7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9rxx-pq63-85w7",
-  "modified": "2025-08-16T12:30:32Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-08-16T12:30:32Z",
   "aliases": [
     "CVE-2025-38521"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Fix kernel crash when hard resetting the GPU\n\nThe GPU hard reset sequence calls pm_runtime_force_suspend() and\npm_runtime_force_resume(), which according to their documentation should\nonly be used during system-wide PM transitions to sleep states.\n\nThe main issue though is that depending on some internal runtime PM\nstate as seen by pm_runtime_force_suspend() (whether the usage count is\n<= 1), pm_runtime_force_resume() might not resume the device unless\nneeded. If that happens, the runtime PM resume callback\npvr_power_device_resume() is not called, the GPU clocks are not\nre-enabled, and the kernel crashes on the next attempt to access GPU\nregisters as part of the power-on sequence.\n\nReplace calls to pm_runtime_force_suspend() and\npm_runtime_force_resume() with direct calls to the driver's runtime PM\ncallbacks, pvr_power_device_suspend() and pvr_power_device_resume(),\nto ensure clocks are re-enabled and avoid the kernel crash.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-668"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-16T11:15:45Z"

advisories/unreviewed/2025/08/GHSA-pm7p-wjq9-6m43/GHSA-pm7p-wjq9-6m43.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-pm7p-wjq9-6m43",
-  "modified": "2025-11-03T18:31:33Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-08-16T12:30:32Z",
   "aliases": [
     "CVE-2025-38503"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion when building free space tree\n\nWhen building the free space tree with the block group tree feature\nenabled, we can hit an assertion failure like this:\n\n  BTRFS info (device loop0 state M): rebuilding free space tree\n  assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/free-space-tree.c:1102!\n  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  sp : ffff8000a4ce7600\n  x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8\n  x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001\n  x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160\n  x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff\n  x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0\n  x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff\n  x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00\n  x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001\n  x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0\n  x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e\n  Call trace:\n   populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)\n   btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337\n   btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n   btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n   btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n   reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n   do_remount fs/namespace.c:3365 [inline]\n   path_mount+0xb34/0xde0 fs/namespace.c:4200\n   do_mount fs/namespace.c:4221 [inline]\n   __do_sys_mount fs/namespace.c:4432 [inline]\n   __se_sys_mount fs/namespace.c:4409 [inline]\n   __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n   el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n   el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n  Code: f0047182 91178042 528089c3 9771d47b (d4210000)\n  ---[ end trace 0000000000000000 ]---\n\nThis happens because we are processing an empty block group, which has\nno extents allocated from it, there are no items for this block group,\nincluding the block group item since block group items are stored in a\ndedicated tree when using the block group tree feature. It also means\nthis is the block group with the highest start offset, so there are no\nhigher keys in the extent root, hence btrfs_search_slot_for_read()\nreturns 1 (no higher key found).\n\nFix this by asserting 'ret' is 0 only if the block group tree feature\nis not enabled, in which case we should find a block group item for\nthe block group since it's stored in the extent root and block group\nitem keys are greater than extent item keys (the value for\nBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and\nBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).\nIn case 'ret' is 1, we just need to add a record to the free space\ntree which spans the whole block group, and we can achieve this by\nmaking 'ret == 0' as the while loop's condition.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -40,8 +45,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-617"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-16T11:15:42Z"

advisories/unreviewed/2025/08/GHSA-rcx5-mm72-w6xv/GHSA-rcx5-mm72-w6xv.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rcx5-mm72-w6xv",
-  "modified": "2025-11-03T18:31:33Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-08-19T18:31:32Z",
   "aliases": [
     "CVE-2025-38560"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -45,7 +50,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-19T17:15:32Z"

advisories/unreviewed/2025/08/GHSA-vc22-mx78-4mgj/GHSA-vc22-mx78-4mgj.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vc22-mx78-4mgj",
-  "modified": "2025-11-03T18:31:33Z",
+  "modified": "2026-01-22T18:50:52Z",
   "published": "2025-08-16T12:30:32Z",
   "aliases": [
     "CVE-2025-38514"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix oops due to non-existence of prealloc backlog struct\n\nIf an AF_RXRPC service socket is opened and bound, but calls are\npreallocated, then rxrpc_alloc_incoming_call() will oops because the\nrxrpc_backlog struct doesn't get allocated until the first preallocation is\nmade.\n\nFix this by returning NULL from rxrpc_alloc_incoming_call() if there is no\nbacklog struct.  This will cause the incoming call to be aborted.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -57,7 +62,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-16T11:15:44Z"

advisories/unreviewed/2025/09/GHSA-29x9-4344-px4h/GHSA-29x9-4344-px4h.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-29x9-4344-px4h",
-  "modified": "2025-11-03T18:31:37Z",
+  "modified": "2026-01-22T18:50:53Z",
   "published": "2025-09-05T18:31:16Z",
   "aliases": [
     "CVE-2025-38694"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()\n\nIn dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and\nmsg[0].len is zero, former checks on msg[0].buf would be passed. If accessing\nmsg[0].buf[2] without sanity check, null pointer deref would happen. We add\ncheck on msg[0].len to prevent crash. Similar issue occurs when access\nmsg[1].buf[0] and msg[1].buf[1].\n\nSimilar commit: commit 0ed554fd769a (\"media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\")",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -60,8 +65,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-476"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-04T16:15:37Z"

advisories/unreviewed/2026/01/GHSA-qj3c-cr7p-g92q/GHSA-qj3c-cr7p-g92q.json

@@ -0,0 +1,48 @@
+{
+  "schema_version": "1.4.0",
+  "id": "GHSA-qj3c-cr7p-g92q",
+  "modified": "2026-01-22T18:50:52Z",
+  "published": "2026-01-22T18:50:52Z",
+  "aliases": [
+    "CVE-2022-49509"
+  ],
+  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: max9286: fix kernel oops when removing module\n\nWhen removing the max9286 module we get a kernel oops:\n\nUnable to handle kernel paging request at virtual address 000000aa00000094\nMem abort info:\n  ESR = 0x96000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004\n  CM = 0, WnR = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000\n[000000aa00000094] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 96000004 [#1] PREEMPT SMP\nModules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec\nCPU: 2 PID: 713 Comm: rmmod Tainted: G         C        5.15.5-00057-gaebcd29c8ed7-dirty #5\nHardware name: Freescale i.MX8QXP MEK (DT)\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : i2c_mux_del_adapters+0x24/0xf0\nlr : max9286_remove+0x28/0xd0 [max9286]\nsp : ffff800013a9bbf0\nx29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000\nx26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000\nx20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8\nx11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098\nx8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\nx5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000\nCall trace:\n i2c_mux_del_adapters+0x24/0xf0\n max9286_remove+0x28/0xd0 [max9286]\n i2c_device_remove+0x40/0x110\n __device_release_driver+0x188/0x234\n driver_detach+0xc4/0x150\n bus_remove_driver+0x60/0xe0\n driver_unregister+0x34/0x64\n i2c_del_driver+0x58/0xa0\n max9286_i2c_driver_exit+0x1c/0x490 [max9286]\n __arm64_sys_delete_module+0x194/0x260\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xd4/0xfc\n do_el0_svc+0x2c/0x94\n el0_svc+0x28/0x80\n el0t_64_sync_handler+0xa8/0x130\n el0t_64_sync+0x1a0/0x1a4\n\nThe Oops happens because the I2C client data does not point to\nmax9286_priv anymore but to v4l2_subdev. The change happened in\nmax9286_init() which calls v4l2_i2c_subdev_init() later on...\n\nBesides fixing the max9286_remove() function, remove the call to\ni2c_set_clientdata() in max9286_probe(), to avoid confusion, and make\nthe necessary changes to max9286_init() so that it doesn't have to use\ni2c_get_clientdata() in order to fetch the pointer to priv.",
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
+    }
+  ],
+  "affected": [],
+  "references": [
+    {
+      "type": "ADVISORY",
+      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49509"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/365ab7ebc24eebb42b9e020aeb440d51af8960cd"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/579c77595dbbdfe4f2edf335899f86ac51eca4e9"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/9dd783274c89c21a038d967b52a858a297e767f8"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/a4ec75df70575cdf33d9638c7844e729bfe6ce24"
+    }
+  ],
+  "database_specific": {
+    "cwe_ids": [
+      "CWE-668"
+    ],
+    "severity": "HIGH",
+    "github_reviewed": false,
+    "github_reviewed_at": null,
+    "nvd_published_at": "2025-02-26T07:01:27Z"
+  }
+}