Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/02/GHSA-q383-xwj3-rcf5/GHSA-q383-xwj3-rcf5.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-q383-xwj3-rcf5",
-  "modified": "2025-02-27T03:34:01Z",
+  "modified": "2025-12-16T18:31:27Z",
   "published": "2025-02-27T03:34:01Z",
   "aliases": [
     "CVE-2025-21710"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn't influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side's notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n//              tcp_v4_rcv(->)\n//                tcp_rcv_established(->)\n[5201<->39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201<->39222]:     tcp_data_queue(->)\n[5201<->39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n                       [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                       [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n                       [OFO queue: gap: 65480, len: 0]\n[5201<->39222]:     tcp_data_queue(<-)\n[5201<->39222]:     __tcp_transmit_skb(->)\n                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]:       tcp_select_window(->)\n[5201<->39222]:         (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE\n                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n                        returning 0\n[5201<->39222]:       tcp_select_window(<-)\n[5201<->39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201<->39222]:     [__tcp_transmit_skb(<-)\n[5201<->39222]:   tcp_rcv_established(<-)\n[5201<->39222]: tcp_v4_rcv(<-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201<->39222]:     [new_win >= (2 * win_now) ? --> time_to_ack = 0]\n[5201<->39222]:     NOT calling tcp_send_ack()\n                    [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]:   __tcp_cleanup_rbuf(<-)\n                  [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                  [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]\n                  returning 6104 bytes\n[5201<->39222]: tcp_recvmsg_locked(<-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp->rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]:     [new_win = 262144, win_now = 131184, 2 * win_n\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": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-667"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-02-27T02:15:14Z"

advisories/unreviewed/2025/07/GHSA-275j-88f3-q9g5/GHSA-275j-88f3-q9g5.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-275j-88f3-q9g5",
-  "modified": "2025-11-03T18:31:20Z",
+  "modified": "2025-12-16T18:31:28Z",
   "published": "2025-07-03T09:30:33Z",
   "aliases": [
     "CVE-2025-38102"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n  RIP: 0010:try_grab_folio+0x106/0x130\n  Call Trace:\n   <TASK>\n   follow_huge_pmd+0x240/0x8e0\n   follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n   follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n   follow_page_mask+0x1c2/0x1f0\n   __get_user_pages+0x176/0x950\n   __gup_longterm_locked+0x15b/0x1060\n   ? gup_fast+0x120/0x1f0\n   gup_fast_fallback+0x17e/0x230\n   get_user_pages_fast+0x5f/0x80\n   vmci_host_unlocked_ioctl+0x21c/0xf80\n  RIP: 0033:0x54d2cd\n  ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context->notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd  // update &context->notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context->notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -56,8 +61,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-03T09:15:23Z"

advisories/unreviewed/2025/07/GHSA-3vxj-mcrg-4r6j/GHSA-3vxj-mcrg-4r6j.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3vxj-mcrg-4r6j",
-  "modified": "2025-11-03T18:31:20Z",
+  "modified": "2025-12-16T18:31:29Z",
   "published": "2025-07-03T09:30:33Z",
   "aliases": [
     "CVE-2025-38108"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: red: fix a race in __red_change()\n\nGerrard Tai reported a race condition in RED, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0                                 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n |                                    [5]: lock root\n |                                    [6]: rehash\n |                                    [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent's qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -56,8 +61,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-03T09:15:24Z"

advisories/unreviewed/2025/07/GHSA-4w5g-r898-rj85/GHSA-4w5g-r898-rj85.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4w5g-r898-rj85",
-  "modified": "2025-11-03T18:31:26Z",
+  "modified": "2025-12-16T18:31:30Z",
   "published": "2025-07-25T15:30:51Z",
   "aliases": [
     "CVE-2025-38365"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix a race between renames and directory logging\n\nWe have a race between a rename and directory inode logging that if it\nhappens and we crash/power fail before the rename completes, the next time\nthe filesystem is mounted, the log replay code will end up deleting the\nfile that was being renamed.\n\nThis is best explained following a step by step analysis of an interleaving\nof steps that lead into this situation.\n\nConsider the initial conditions:\n\n1) We are at transaction N;\n\n2) We have directories A and B created in a past transaction (< N);\n\n3) We have inode X corresponding to a file that has 2 hardlinks, one in\n   directory A and the other in directory B, so we'll name them as\n   \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a\n   past transaction (< N);\n\n4) We have inode Y corresponding to a file that as a single hard link and\n   is located in directory A, we'll name it as \"A/bar\". This file was also\n   persisted in a past transaction (< N).\n\nThe steps leading to a file loss are the following and for all of them we\nare under transaction N:\n\n 1) Link \"A/foo_link1\" is removed, so inode's X last_unlink_trans field\n    is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir();\n\n 2) Task A starts a rename for inode Y, with the goal of renaming from\n    \"A/bar\" to \"A/baz\", so we enter btrfs_rename();\n\n 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling\n    btrfs_insert_inode_ref();\n\n 4) Because the rename happens in the same directory, we don't set the\n    last_unlink_trans field of directoty A's inode to the current\n    transaction id, that is, we don't cal btrfs_record_unlink_dir();\n\n 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY\n    and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()\n    (actually the dir index item is added as a delayed item, but the\n    effect is the same);\n\n 6) Now before task A adds the new entry \"A/baz\" to directory A by\n    calling btrfs_add_link(), another task, task B is logging inode X;\n\n 7) Task B starts a fsync of inode X and after logging inode X, at\n    btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since\n    inode X has a last_unlink_trans value of N, set at in step 1;\n\n 8) At btrfs_log_all_parents() we search for all parent directories of\n    inode X using the commit root, so we find directories A and B and log\n    them. Bu when logging direct A, we don't have a dir index item for\n    inode Y anymore, neither the old name \"A/bar\" nor for the new name\n    \"A/baz\" since the rename has deleted the old name but has not yet\n    inserted the new name - task A hasn't called yet btrfs_add_link() to\n    do that.\n\n    Note that logging directory A doesn't fallback to a transaction\n    commit because its last_unlink_trans has a lower value than the\n    current transaction's id (see step 4);\n\n 9) Task B finishes logging directories A and B and gets back to\n    btrfs_sync_file() where it calls btrfs_sync_log() to persist the log\n    tree;\n\n10) Task B successfully persisted the log tree, btrfs_sync_log() completed\n    with success, and a power failure happened.\n\n    We have a log tree without any directory entry for inode Y, so the\n    log replay code deletes the entry for inode Y, name \"A/bar\", from the\n    subvolume tree since it doesn't exist in the log tree and the log\n    tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY\n    item that covers the index range for the dentry that corresponds to\n    \"A/bar\").\n\n    Since there's no other hard link for inode Y and the log replay code\n    deletes the name \"A/bar\", the file is lost.\n\nThe issue wouldn't happen if task B synced the log only after task A\ncalled btrfs_log_new_name(), which would update the log with the new name\nfor inode Y (\"A/bar\").\n\nFix this by pinning the log root during renames before removing the old\ndirectory entry, and unpinning af\n---truncated---",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/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-362"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-25T13:15:25Z"

advisories/unreviewed/2025/07/GHSA-6fmq-5w8g-7pm6/GHSA-6fmq-5w8g-7pm6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6fmq-5w8g-7pm6",
-  "modified": "2025-11-03T18:31:20Z",
+  "modified": "2025-12-16T18:31:29Z",
   "published": "2025-07-03T09:30:33Z",
   "aliases": [
     "CVE-2025-38107"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: ets: fix a race in ets_qdisc_change()\n\nGerrard Tai reported a race condition in ETS, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0                                 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n |                                    [5]: lock root\n |                                    [6]: rehash\n |                                    [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent's qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -52,8 +57,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-03T09:15:24Z"

advisories/unreviewed/2025/07/GHSA-6mr5-83vp-r7m7/GHSA-6mr5-83vp-r7m7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6mr5-83vp-r7m7",
-  "modified": "2025-11-03T18:31:25Z",
+  "modified": "2025-12-16T18:31:30Z",
   "published": "2025-07-19T09:30:40Z",
   "aliases": [
     "CVE-2025-38350"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes' dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent's parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n    tc qdisc add dev lo root handle 1: drr\n    tc filter add dev lo parent 1: basic classid 1:1\n    tc class add dev lo parent 1: classid 1:1 drr\n    tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n    tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n    tc qdisc add dev lo parent 2:1 handle 3: netem\n    tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n    tc class delete dev lo classid 1:1\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -56,8 +61,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-19T07:15:22Z"