Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/09/GHSA-2h47-q9f6-8gx7/GHSA-2h47-q9f6-8gx7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2h47-q9f6-8gx7",
-  "modified": "2025-09-15T15:31:28Z",
+  "modified": "2025-12-04T15:30:31Z",
   "published": "2025-09-15T15:31:28Z",
   "aliases": [
     "CVE-2023-53208"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state\n\nWhen emulating nested VM-Exit, load L1's TSC multiplier if L1's desired\nratio doesn't match the current ratio, not if the ratio L1 is using for\nL2 diverges from the default.  Functionally, the end result is the same\nas KVM will run L2 with L1's multiplier if L2's multiplier is the default,\ni.e. checking that L1's multiplier is loaded is equivalent to checking if\nL2 has a non-default multiplier.\n\nHowever, the assertion that TSC scaling is exposed to L1 is flawed, as\nuserspace can trigger the WARN at will by writing the MSR and then\nupdating guest CPUID to hide the feature (modifying guest CPUID is\nallowed anytime before KVM_RUN).  E.g. hacking KVM's state_test\nselftest to do\n\n                vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);\n                vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);\n\nafter restoring state in a new VM+vCPU yields an endless supply of:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105\n           nested_svm_vmexit+0x6af/0x720 [kvm_amd]\n  Call Trace:\n   nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]\n   svm_handle_exit+0xb9/0x180 [kvm_amd]\n   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]\n   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]\n   ? trace_hardirqs_off+0x4d/0xa0\n   __se_sys_ioctl+0x7a/0xc0\n   __x64_sys_ioctl+0x21/0x30\n   do_syscall_64+0x41/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUnlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check\ninto the if-statement is wrong as KVM needs to ensure L1's multiplier is\nloaded in the above scenario.   Alternatively, the WARN_ON() could simply\nbe deleted, but that would make KVM's behavior even more subtle, e.g. it's\nnot immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when\nchecking only tsc_ratio_msr.",
-  "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-09-15T15:15:47Z"

advisories/unreviewed/2025/09/GHSA-3277-7c79-2vxw/GHSA-3277-7c79-2vxw.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3277-7c79-2vxw",
-  "modified": "2025-09-15T15:31:29Z",
+  "modified": "2025-12-04T15:30:32Z",
   "published": "2025-09-15T15:31:28Z",
   "aliases": [
     "CVE-2023-53222"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: jfs_dmap: Validate db_l2nbperpage while mounting\n\nIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block\nnumber inside dbFree(). db_l2nbperpage, which is the log2 number of\nblocks per page, is passed as an argument to BLKTODMAP which uses it\nfor shifting.\n\nSyzbot reported a shift out-of-bounds crash because db_l2nbperpage is\ntoo big. This happens because the large value is set without any\nvalidation in dbMount() at line 181.\n\nThus, make sure that db_l2nbperpage is correct while mounting.\n\nMax number of blocks per page = Page size / Min block size\n=> log2(Max num_block per page) = log2(Page size / Min block size)\n\t\t\t\t= log2(Page size) - log2(Min block size)\n\n=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE",
-  "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-125"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T15:15:48Z"

advisories/unreviewed/2025/09/GHSA-3cwp-rh3m-h6g8/GHSA-3cwp-rh3m-h6g8.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3cwp-rh3m-h6g8",
-  "modified": "2025-09-15T15:31:27Z",
+  "modified": "2025-12-04T15:30:30Z",
   "published": "2025-09-15T15:31:27Z",
   "aliases": [
     "CVE-2022-50323"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: do not sense pfmemalloc status in skb_append_pagefrags()\n\nskb_append_pagefrags() is used by af_unix and udp sendpage()\nimplementation so far.\n\nIn commit 326140063946 (\"tcp: TX zerocopy should not sense\npfmemalloc status\") we explained why we should not sense\npfmemalloc status for pages owned by user space.\n\nWe should also use skb_fill_page_desc_noacc()\nin skb_append_pagefrags() to avoid following KCSAN report:\n\nBUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags\n\nwrite to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:323 [inline]\nlru_add_fn+0x327/0x410 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nlru_add_drain_cpu+0x73/0x250 mm/swap.c:669\nlru_add_drain+0x21/0x60 mm/swap.c:773\nfree_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311\ntlb_batch_pages_flush mm/mmu_gather.c:59 [inline]\ntlb_flush_mmu_free mm/mmu_gather.c:256 [inline]\ntlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263\ntlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363\nexit_mmap+0x190/0x4d0 mm/mmap.c:3098\n__mmput+0x27/0x1b0 kernel/fork.c:1185\nmmput+0x3d/0x50 kernel/fork.c:1207\ncopy_process+0x19fc/0x2100 kernel/fork.c:2518\nkernel_clone+0x166/0x550 kernel/fork.c:2671\n__do_sys_clone kernel/fork.c:2812 [inline]\n__se_sys_clone kernel/fork.c:2796 [inline]\n__x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1817 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2432 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2453 [inline]\nskb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974\nunix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1255\n__do_sys_sendfile64 fs/read_write.c:1323 [inline]\n__se_sys_sendfile64 fs/read_write.c:1309 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0x0000000000000000 -> 0xffffea00058fc188\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022",
-  "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-09-15T15:15:44Z"

advisories/unreviewed/2025/09/GHSA-3ghw-3m72-v6jr/GHSA-3ghw-3m72-v6jr.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3ghw-3m72-v6jr",
-  "modified": "2025-09-15T15:31:27Z",
+  "modified": "2025-12-04T15:30:30Z",
   "published": "2025-09-15T15:31:27Z",
   "aliases": [
     "CVE-2022-50319"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: trbe: remove cpuhp instance node before remove cpuhp state\n\ncpuhp_state_add_instance() and cpuhp_state_remove_instance() should\nbe used in pairs. Or there will lead to the warn on\ncpuhp_remove_multi_state() since the cpuhp_step list is not empty.\n\nThe following is the error log with 'rmmod coresight-trbe':\nError: Removing state 215 which has instances left.\nCall trace:\n  __cpuhp_remove_state_cpuslocked+0x144/0x160\n  __cpuhp_remove_state+0xac/0x100\n  arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]\n  platform_remove+0x34/0x70\n  device_remove+0x54/0x90\n  device_release_driver_internal+0x1e4/0x250\n  driver_detach+0x5c/0xb0\n  bus_remove_driver+0x64/0xc0\n  driver_unregister+0x3c/0x70\n  platform_driver_unregister+0x20/0x30\n  arm_trbe_exit+0x1c/0x658 [coresight_trbe]\n  __arm64_sys_delete_module+0x1ac/0x24c\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0x58/0x1a0\n  do_el0_svc+0x38/0xd0\n  el0_svc+0x2c/0xc0\n  el0t_64_sync_handler+0x1ac/0x1b0\n  el0t_64_sync+0x19c/0x1a0\n ---[ end trace 0000000000000000 ]---",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T15:15:43Z"

advisories/unreviewed/2025/09/GHSA-3pxv-j5r5-v5qh/GHSA-3pxv-j5r5-v5qh.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3pxv-j5r5-v5qh",
-  "modified": "2025-09-15T15:31:26Z",
+  "modified": "2025-12-04T15:30:30Z",
   "published": "2025-09-15T15:31:25Z",
   "aliases": [
     "CVE-2022-50280"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npnode: terminate at peers of source\n\nThe propagate_mnt() function handles mount propagation when creating\nmounts and propagates the source mount tree @source_mnt to all\napplicable nodes of the destination propagation mount tree headed by\n@dest_mnt.\n\nUnfortunately it contains a bug where it fails to terminate at peers of\n@source_mnt when looking up copies of the source mount that become\nmasters for copies of the source mount tree mounted on top of slaves in\nthe destination propagation tree causing a NULL dereference.\n\nOnce the mechanics of the bug are understood it's easy to trigger.\nBecause of unprivileged user namespaces it is available to unprivileged\nusers.\n\nWhile fixing this bug we've gotten confused multiple times due to\nunclear terminology or missing concepts. So let's start this with some\nclarifications:\n\n* The terms \"master\" or \"peer\" denote a shared mount. A shared mount\n  belongs to a peer group.\n\n* A peer group is a set of shared mounts that propagate to each other.\n  They are identified by a peer group id. The peer group id is available\n  in @shared_mnt->mnt_group_id.\n  Shared mounts within the same peer group have the same peer group id.\n  The peers in a peer group can be reached via @shared_mnt->mnt_share.\n\n* The terms \"slave mount\" or \"dependent mount\" denote a mount that\n  receives propagation from a peer in a peer group. IOW, shared mounts\n  may have slave mounts and slave mounts have shared mounts as their\n  master. Slave mounts of a given peer in a peer group are listed on\n  that peers slave list available at @shared_mnt->mnt_slave_list.\n\n* The term \"master mount\" denotes a mount in a peer group. IOW, it\n  denotes a shared mount or a peer mount in a peer group. The term\n  \"master mount\" - or \"master\" for short - is mostly used when talking\n  in the context of slave mounts that receive propagation from a master\n  mount. A master mount of a slave identifies the closest peer group a\n  slave mount receives propagation from. The master mount of a slave can\n  be identified via @slave_mount->mnt_master. Different slaves may point\n  to different masters in the same peer group.\n\n* Multiple peers in a peer group can have non-empty ->mnt_slave_lists.\n  Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to\n  ensure all slave mounts of a peer group are visited the\n  ->mnt_slave_lists of all peers in a peer group have to be walked.\n\n* Slave mounts point to a peer in the closest peer group they receive\n  propagation from via @slave_mnt->mnt_master (see above). Together with\n  these peers they form a propagation group (see below). The closest\n  peer group can thus be identified through the peer group id\n  @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave\n  mount receives propagation from.\n\n* A shared-slave mount is a slave mount to a peer group pg1 while also\n  a peer in another peer group pg2. IOW, a peer group may receive\n  propagation from another peer group.\n\n  If a peer group pg1 is a slave to another peer group pg2 then all\n  peers in peer group pg1 point to the same peer in peer group pg2 via\n  ->mnt_master. IOW, all peers in peer group pg1 appear on the same\n  ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.\n\n* A pure slave mount is a slave mount that is a slave to a peer group\n  but is not a peer in another peer group.\n\n* A propagation group denotes the set of mounts consisting of a single\n  peer group pg1 and all slave mounts and shared-slave mounts that point\n  to a peer in that peer group via ->mnt_master. IOW, all slave mounts\n  such that @slave_mnt->mnt_master->mnt_group_id is equal to\n  @shared_mnt->mnt_group_id.\n\n  The concept of a propagation group makes it easier to talk about a\n  single propagation level in a propagation tree.\n\n  For example, in propagate_mnt() the immediate peers of @dest_mnt and\n  all slaves of @dest_mnt's peer group form a propagation group pr\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": [
     {
@@ -52,8 +57,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-15T15:15:39Z"

advisories/unreviewed/2025/09/GHSA-422j-5566-qw87/GHSA-422j-5566-qw87.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-422j-5566-qw87",
-  "modified": "2025-09-15T15:31:27Z",
+  "modified": "2025-12-04T15:30:31Z",
   "published": "2025-09-15T15:31:27Z",
   "aliases": [
     "CVE-2022-50332"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvideo/aperture: Call sysfb_disable() before removing PCI devices\n\nCall sysfb_disable() from aperture_remove_conflicting_pci_devices()\nbefore removing PCI devices. Without, simpledrm can still bind to\nsimple-framebuffer devices after the hardware driver has taken over\nthe hardware. Both drivers interfere with each other and results are\nundefined.\n\nReported modesetting errors [1] are shown below.\n\n---- snap ----\nrcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.\nrcu: blocking rcu_node structures (internal RCU debug):\nTask dump for CPU 13:\ntask:X               state:R  running task     stack:    0 pid: 4242 ppid:  4228 flags:0x00000008\nCall Trace:\n <TASK>\n ? commit_tail+0xd7/0x130\n ? drm_atomic_helper_commit+0x126/0x150\n ? drm_atomic_commit+0xa4/0xe0\n ? drm_plane_get_damage_clips.cold+0x1c/0x1c\n ? drm_atomic_helper_dirtyfb+0x19e/0x280\n ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? drm_ioctl_kernel+0xc4/0x150\n ? drm_ioctl+0x246/0x3f0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? __x64_sys_ioctl+0x91/0xd0\n ? do_syscall_64+0x60/0xd0\n ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5\n </TASK>\n...\nrcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.\nrcu: blocking rcu_node structures (internal RCU debug):\nTask dump for CPU 13:\ntask:X               state:R  running task     stack:    0 pid: 4242 ppid:  4228 flags:0x0000400e\nCall Trace:\n <TASK>\n ? memcpy_toio+0x76/0xc0\n ? memcpy_toio+0x1b/0xc0\n ? drm_fb_memcpy_toio+0x76/0xb0\n ? drm_fb_blit_toio+0x75/0x2b0\n ? simpledrm_simple_display_pipe_update+0x132/0x150\n ? drm_atomic_helper_commit_planes+0xb6/0x230\n ? drm_atomic_helper_commit_tail+0x44/0x80\n ? commit_tail+0xd7/0x130\n ? drm_atomic_helper_commit+0x126/0x150\n ? drm_atomic_commit+0xa4/0xe0\n ? drm_plane_get_damage_clips.cold+0x1c/0x1c\n ? drm_atomic_helper_dirtyfb+0x19e/0x280\n ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? drm_ioctl_kernel+0xc4/0x150\n ? drm_ioctl+0x246/0x3f0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? __x64_sys_ioctl+0x91/0xd0\n ? do_syscall_64+0x60/0xd0\n ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5\n </TASK>\n\nThe problem was added by commit 5e0137612430 (\"video/aperture: Disable\nand unregister sysfb devices via aperture helpers\") to v6.0.3 and does\nnot exist in the mainline branch.\n\nThe mainline commit 5e0137612430 (\"video/aperture: Disable and\nunregister sysfb devices via aperture helpers\") has been backported\nfrom v6.0-rc1 to stable v6.0.3 from a larger patch series [2] that\nreworks fbdev framebuffer ownership. The backport misses a change to\naperture_remove_conflicting_pci_devices(). Mainline itself is fine,\nbecause the function does not exist there as a result of the patch\nseries.\n\nInstead of backporting the whole series, fix the additional function.",
-  "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": [
     {
@@ -21,7 +26,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T15:15:45Z"

advisories/unreviewed/2025/09/GHSA-48x8-gfgf-f9w8/GHSA-48x8-gfgf-f9w8.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-48x8-gfgf-f9w8",
-  "modified": "2025-09-15T15:31:29Z",
+  "modified": "2025-12-04T15:30:32Z",
   "published": "2025-09-15T15:31:29Z",
   "aliases": [
     "CVE-2023-53237"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini\n\nThe gmc.ecc_irq is enabled by firmware per IFWI setting,\nand the host driver is not privileged to enable/disable\nthe interrupt. So, it is meaningless to use the amdgpu_irq_put\nfunction in gmc_v11_0_hw_fini, which also leads to the call\ntrace.\n\n[  102.980303] Call Trace:\n[  102.980303]  <TASK>\n[  102.980304]  gmc_v11_0_hw_fini+0x54/0x90 [amdgpu]\n[  102.980357]  gmc_v11_0_suspend+0xe/0x20 [amdgpu]\n[  102.980409]  amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]\n[  102.980459]  amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]\n[  102.980520]  amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]\n[  102.980573]  amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]\n[  102.980687]  amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]\n[  102.980740]  process_one_work+0x21f/0x3f0\n[  102.980741]  worker_thread+0x200/0x3e0\n[  102.980742]  ? process_one_work+0x3f0/0x3f0\n[  102.980743]  kthread+0xfd/0x130\n[  102.980743]  ? kthread_complete_and_exit+0x20/0x20\n[  102.980744]  ret_from_fork+0x22/0x30",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T15:15:50Z"