Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2024/05/GHSA-v5mc-ffgc-f77v/GHSA-v5mc-ffgc-f77v.json

@@ -1,12 +1,12 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-v5mc-ffgc-f77v",
-  "modified": "2024-05-08T15:30:43Z",
+  "modified": "2025-10-21T12:31:20Z",
   "published": "2024-05-08T15:30:43Z",
   "aliases": [
     "CVE-2024-32761"
   ],
-  "details": "\nUnder certain conditions, a potential data leak may occur in the Traffic Management Microkernels (TMMs) of BIG-IP tenants running on VELOS and rSeries platforms. However, this issue cannot be exploited by an attacker because it is not consistently reproducible and is beyond an attacker's control.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
+  "details": "Under certain conditions, a potential data leak may occur in the Traffic Management Microkernels (TMMs) of BIG-IP tenants running on VELOS and rSeries platforms. However, this issue cannot be exploited by an attacker because it is not consistently reproducible and is beyond an attacker's control.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/unreviewed/2024/10/GHSA-gfc8-6qcc-3mvm/GHSA-gfc8-6qcc-3mvm.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-gfc8-6qcc-3mvm",
-  "modified": "2024-10-16T15:32:08Z",
+  "modified": "2025-10-21T12:31:20Z",
   "published": "2024-10-16T15:32:08Z",
   "aliases": [
     "CVE-2024-45844"
@@ -26,6 +26,10 @@
     {
       "type": "WEB",
       "url": "https://my.f5.com/manage/s/article/K000140061"
+    },
+    {
+      "type": "WEB",
+      "url": "https://offsec.almond.consulting/privilege-escalation-f5-CVE-2024-45844.html"
     }
   ],
   "database_specific": {

advisories/unreviewed/2025/01/GHSA-3xg6-m2m6-mr95/GHSA-3xg6-m2m6-mr95.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3xg6-m2m6-mr95",
-  "modified": "2025-01-15T15:31:25Z",
+  "modified": "2025-10-21T12:31:21Z",
   "published": "2025-01-15T15:31:25Z",
   "aliases": [
     "CVE-2024-57897"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Correct the migration DMA map direction\n\nThe SVM DMA device map direction should be set the same as\nthe DMA unmap setting, otherwise the DMA core will report\nthe following warning.\n\nBefore finialize this solution, there're some discussion on\nthe DMA mapping type(stream-based or coherent) in this KFD\nmigration case, followed by https://lore.kernel.org/all/04d4ab32\[email protected]/T/.\n\nAs there's no dma_sync_single_for_*() in the DMA buffer accessed\nthat because this migration operation should be sync properly and\nautomatically. Give that there's might not be a performance problem\nin various cache sync policy of DMA sync. Therefore, in order to\nsimplify the DMA direction setting alignment, let's set the DMA map\ndirection as BIDIRECTIONAL.\n\n[  150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930\n[  150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds\n[  150.834310]  wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[  150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G           OE      6.10.0-custom #492\n[  150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[  150.834360] RIP: 0010:check_unmap+0x1cc/0x930\n[  150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50\n[  150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086\n[  150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027\n[  150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680\n[  150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850\n[  150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40\n[  150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b\n[  150.834377] FS:  00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000\n[  150.834379] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0\n[  150.834383] Call Trace:\n[  150.834385]  <TASK>\n[  150.834387]  ? show_regs+0x6d/0x80\n[  150.834393]  ? __warn+0x8c/0x140\n[  150.834397]  ? check_unmap+0x1cc/0x930\n[  150.834400]  ? report_bug+0x193/0x1a0\n[  150.834406]  ? handle_bug+0x46/0x80\n[  150.834410]  ? exc_invalid_op+0x1d/0x80\n[  150.834413]  ? asm_exc_invalid_op+0x1f/0x30\n[  150.834420]  ? check_unmap+0x1cc/0x930\n[  150.834425]  debug_dma_unmap_page+0x86/0x90\n[  150.834431]  ? srso_return_thunk+0x5/0x5f\n[  150.834435] \n---truncated---",
-  "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": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-01-15T13:15:14Z"

advisories/unreviewed/2025/01/GHSA-5fgm-r8gc-2w6h/GHSA-5fgm-r8gc-2w6h.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5fgm-r8gc-2w6h",
-  "modified": "2025-01-17T15:32:32Z",
+  "modified": "2025-10-21T12:31:21Z",
   "published": "2025-01-15T15:31:24Z",
   "aliases": [
     "CVE-2024-57888"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker\n\nAfter commit\n746ae46c1113 (\"drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\")\namdgpu started seeing the following warning:\n\n [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]\n...\n [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]\n...\n [ ] Call Trace:\n [ ]  <TASK>\n...\n [ ]  ? check_flush_dependency+0xf5/0x110\n...\n [ ]  cancel_delayed_work_sync+0x6e/0x80\n [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]\n [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]\n [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]\n [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]\n [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]\n [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]\n [ ]  process_one_work+0x217/0x720\n...\n [ ]  </TASK>\n\nThe intent of the verifcation done in check_flush_depedency is to ensure\nforward progress during memory reclaim, by flagging cases when either a\nmemory reclaim process, or a memory reclaim work item is flushed from a\ncontext not marked as memory reclaim safe.\n\nThis is correct when flushing, but when called from the\ncancel(_delayed)_work_sync() paths it is a false positive because work is\neither already running, or will not be running at all. Therefore\ncancelling it is safe and we can relax the warning criteria by letting the\nhelper know of the calling context.\n\nReferences: 746ae46c1113 (\"drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\")",
-  "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": [
     {
@@ -29,7 +34,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-01-15T13:15:13Z"

advisories/unreviewed/2025/06/GHSA-qq62-42pv-vwvh/GHSA-qq62-42pv-vwvh.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-qq62-42pv-vwvh",
-  "modified": "2025-06-19T15:30:30Z",
+  "modified": "2025-10-21T12:31:25Z",
   "published": "2025-06-19T15:30:30Z",
   "aliases": [
     "CVE-2022-49352"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix warning in ext4_handle_inode_extension\n\nWe got issue as follows:\nEXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory\nEXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error\nEXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory\nEXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220\nModules linked in:\nCPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1\nRIP: 0010:ext4_file_write_iter+0x11c9/0x1220\nRSP: 0018:ffff924d80b27c00 EFLAGS: 00010282\nRAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000\nRDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd\nRBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f\nR10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a\nR13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b\nFS:  00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n do_iter_readv_writev+0x2e5/0x360\n do_iter_write+0x112/0x4c0\n do_pwritev+0x1e5/0x390\n __x64_sys_pwritev2+0x7e/0xa0\n do_syscall_64+0x37/0x50\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nAbove issue may happen as follows:\nAssume\ninode.i_size=4096\nEXT4_I(inode)->i_disksize=4096\n\nstep 1: set inode->i_isize = 8192\next4_setattr\n  if (attr->ia_size != inode->i_size)\n    EXT4_I(inode)->i_disksize = attr->ia_size;\n    rc = ext4_mark_inode_dirty\n       ext4_reserve_inode_write\n          ext4_get_inode_loc\n            __ext4_get_inode_loc\n              sb_getblk --> return -ENOMEM\n   ...\n   if (!error)  ->will not update i_size\n     i_size_write(inode, attr->ia_size);\nNow:\ninode.i_size=4096\nEXT4_I(inode)->i_disksize=8192\n\nstep 2: Direct write 4096 bytes\next4_file_write_iter\n ext4_dio_write_iter\n   iomap_dio_rw ->return error\n if (extend)\n   ext4_handle_inode_extension\n     WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize);\n->Then trigger warning.\n\nTo solve above issue, if mark inode dirty failed in ext4_setattr just\nset 'EXT4_I(inode)->i_disksize' with old value.",
-  "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": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-02-26T07:01:11Z"

advisories/unreviewed/2025/10/GHSA-2c59-vh4j-7xh2/GHSA-2c59-vh4j-7xh2.json

@@ -0,0 +1,58 @@
+{
+  "schema_version": "1.4.0",
+  "id": "GHSA-2c59-vh4j-7xh2",
+  "modified": "2025-10-21T12:31:25Z",
+  "published": "2025-10-21T12:31:25Z",
+  "aliases": [
+    "CVE-2022-49341"
+  ],
+  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Clear prog->jited_len along prog->jited\n\nsyzbot reported an illegal copy_to_user() attempt\nfrom bpf_prog_get_info_by_fd() [1]\n\nThere was no repro yet on this bug, but I think\nthat commit 0aef499f3172 (\"mm/usercopy: Detect vmalloc overruns\")\nis exposing a prior bug in bpf arm64.\n\nbpf_prog_get_info_by_fd() looks at prog->jited_len\nto determine if the JIT image can be copied out to user space.\n\nMy theory is that syzbot managed to get a prog where prog->jited_len\nhas been set to 43, while prog->bpf_func has ben cleared.\n\nIt is not clear why copy_to_user(uinsns, NULL, ulen) is triggering\nthis particular warning.\n\nI thought find_vma_area(NULL) would not find a vm_struct.\nAs we do not hold vmap_area_lock spinlock, it might be possible\nthat the found vm_struct was garbage.\n\n[1]\nusercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!\nkernel BUG at mm/usercopy.c:101!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0\nHardware name: linux,dummy-virt (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usercopy_abort+0x90/0x94 mm/usercopy.c:101\nlr : usercopy_abort+0x90/0x94 mm/usercopy.c:89\nsp : ffff80000b773a20\nx29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48\nx26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000\nx23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001\nx20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd\nx17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420\nx14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031\nx11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865\nx8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830\nx5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064\nCall trace:\n usercopy_abort+0x90/0x94 mm/usercopy.c:89\n check_heap_object mm/usercopy.c:186 [inline]\n __check_object_size mm/usercopy.c:252 [inline]\n __check_object_size+0x198/0x36c mm/usercopy.c:214\n check_object_size include/linux/thread_info.h:199 [inline]\n check_copy_size include/linux/thread_info.h:235 [inline]\n copy_to_user include/linux/uaccess.h:159 [inline]\n bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993\n bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253\n __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956\n __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]\n __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019\n __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]\n invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52\n el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142\n do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206\n el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624\n el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581\nCode: aa0003e3 d00038c0 91248000 97fff65f (d4210000)",
+  "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": [
+    {
+      "type": "ADVISORY",
+      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49341"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be"
+    }
+  ],
+  "database_specific": {
+    "cwe_ids": [],
+    "severity": "MODERATE",
+    "github_reviewed": false,
+    "github_reviewed_at": null,
+    "nvd_published_at": "2025-02-26T07:01:10Z"
+  }
+}

advisories/unreviewed/2025/10/GHSA-2rh7-4r32-mrr5/GHSA-2rh7-4r32-mrr5.json

@@ -0,0 +1,38 @@
+{
+  "schema_version": "1.4.0",
+  "id": "GHSA-2rh7-4r32-mrr5",
+  "modified": "2025-10-21T12:31:26Z",
+  "published": "2025-10-21T12:31:26Z",
+  "aliases": [
+    "CVE-2022-49504"
+  ],
+  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Inhibit aborts if external loopback plug is inserted\n\nAfter running a short external loopback test, when the external loopback is\nremoved and a normal cable inserted that is directly connected to a target\ndevice, the system oops in the llpfc_set_rrq_active() routine.\n\nWhen the loopback was inserted an FLOGI was transmit. As we're looped back,\nwe receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same\nwppn thus understand it's a loopback. However, as the ABTS sends address\ninformation the port is not set to (fffffe), the ABTS is dropped on the\nwire. A short 1 frame loopback test is run and completes before the ABTS\ntimes out. The looback is unplugged and the new cable plugged in, and the\nan FLOGI to the new device occurs and completes. Due to a mixup in ref\ncounting the completion of the new FLOGI releases the fabric ndlp. Then the\noriginal ABTS completes and references the released ndlp generating the\noops.\n\nCorrect by no-op'ing the ABTS when in loopback mode (it will be dropped\nanyway). Added a flag to track the mode to recognize when it should be\nno-op'd.",
+  "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": [
+    {
+      "type": "ADVISORY",
+      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49504"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/a1516930cb605caee3bc7b4f3b7994b88c0b8505"
+    },
+    {
+      "type": "WEB",
+      "url": "https://git.kernel.org/stable/c/ead76d4c09b89f4c8d632648026a476a5a34fde8"
+    }
+  ],
+  "database_specific": {
+    "cwe_ids": [],
+    "severity": "MODERATE",
+    "github_reviewed": false,
+    "github_reviewed_at": null,
+    "nvd_published_at": "2025-02-26T07:01:26Z"
+  }
+}