Sync Collecting Fix Commits: Mon May 18 23:40:27 UTC 2026

Signed-off-by: AboutCode Automation <automation@aboutcode.org>

Author: aboutcode-automation

data/fix-commits/advisory-database-b78f1d41.json

@@ -2,12 +2,14 @@
   "vcs_url": "https://github.com/python/cpython",
   "vulnerabilities": {
     "CVE-2021-4189": {
+      "c88704431ea3248ca769384c13856330976fac1d": "[3.12] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149795)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "5dadc64673ce875ebfb24163907777dae0f6ca06": "[3.15] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149792)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "7d95a1dc7382b55cba7fdd6a110336077584a4f0": "[3.14] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149793)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "bb3446dda6c49b32e67c11dbbbf221b40be00763": "[3.13] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149794)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "eac4fe3b2c77693790a5ef7dfab127c1fee81bf9": "gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)"
     },
     "GHSA-W8C5-Q2XF-GF7C": {
+      "c88704431ea3248ca769384c13856330976fac1d": "[3.12] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149795)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "5dadc64673ce875ebfb24163907777dae0f6ca06": "[3.15] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149792)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "7d95a1dc7382b55cba7fdd6a110336077584a4f0": "[3.14] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149793)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",
       "bb3446dda6c49b32e67c11dbbbf221b40be00763": "[3.13] gh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648) (#149794)\n\ngh-87451: Apply CVE-2021-4189 PASV fix to ftplib.ftpcp() (GH-149648)\n\nftpcp() called parse227() directly and passed the source server's\nself-reported PASV IPv4 address to the target server's PORT command,\nbypassing the CVE-2021-4189 fix that was applied only to FTP.makepasv().\nA malicious source FTP server could use this to redirect the target\nserver's data connection to an arbitrary host:port (SSRF).\n\nftpcp() now uses the source server's actual peer address, honoring the\nexisting trust_server_pasv_ipv4_address opt-out, the same as makepasv().\n\nThanks to Qi Ding at Aurascape AI for the report. (GHSA-w8c5-q2xf-gf7c)\n(cherry picked from commit eac4fe3b2c77693790a5ef7dfab127c1fee81bf9)\n\nCo-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>",

data/fix-commits/cpython-cd1cb5b5.json

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/apache/druid",
   "vulnerabilities": {
+    "CVE-2026-5588": {
+      "b04b349bef32eb0ddc0fd799c5d1e5a57eed034a": "bump bouncy castle due to CVE-2026-5588 (#19473)"
+    },
     "CVE-2026-33186": {
       "27556bab76080004e519d468659d975cb591e80c": "suppress-CVE-2026-33186"
     },

data/fix-commits/druid-612f0710.json

@@ -1,6 +1,10 @@
 {
   "vcs_url": "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git",
   "vulnerabilities": {
+    "CVE-2025-48514": {
+      "d8355a92df1f016bcb2fdb0cc9fc7bd13b6588dc": "KVM: SEV: Don't advertise VM types that are disabled by firmware\n\nAs called out in a footnote for a recent SNP vulnerability[1], it is\npossible for a specific flavor of SEV+ to be disabled by the firmware even\nwhen the flavor is fully supported by the CPU and platform:\n\n  Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when\n  SEV-SNP is enabled.\n\nRestrict KVM's set of supported VM types based on the VM types that are\nfully supported by firmware to avoid over-reporting what KVM can actually\nsupport.  Like KVM's handling of ASID space exhaustion, don't modify KVM's\nCPUID capabilities, as the CPU/platform still supports the underlying\ntechnology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse\nKVM and userspace.\n\nLink: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1]\nLink: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com\nSuggested-by: Sean Christopherson <seanjc@google.com>\nSigned-off-by: Tycho Andersen (AMD) <tycho@kernel.org>\n[sean: rewrite changelog to provide details on why/how this can happen]\nReviewed-by: Tom Lendacky <thomas.lendacky@amd.com>\nTested-by: Tycho Andersen (AMD) <tycho@kernel.org>\nLink: https://patch.msgid.link/20260416232329.3408497-7-seanjc@google.com\nSigned-off-by: Sean Christopherson <seanjc@google.com>",
+      "4b28f0846ef6521b47ee95ea7d77c9d40a7baf29": "crypto/ccp: export firmware supported vm types\n\nIn some configurations, the firmware does not support all VM types. The SEV\nfirmware has an entry in the TCB_VERSION structure referred to as the\nSecurity Version Number in the SEV-SNP firmware specification and referred\nto as the \"SPL\" in SEV firmware release notes. The SEV firmware release\nnotes say:\n\n    On every SEV firmware release where a security mitigation has been\n    added, the SNP SPL gets increased by 1. This is to let users know that\n    it is important to update to this version.\n\nThe SEV firmware release that fixed CVE-2025-48514 by disabling SEV-ES\nsupport on vulnerable platforms has this SVN increased to reflect the fix.\nThe SVN is platform-specific, as is the structure of TCB_VERSION.\n\nCheck CURRENT_TCB instead of REPORTED_TCB, since the firmware behaves with\nthe CURRENT_TCB SVN level and will reject SEV-ES VMs accordingly.\n\nParse the SVN, and mask off the SEV_ES supported VM type from the list of\nsupported types if it is above the per-platform threshold for the relevant\nplatforms.\n\nSigned-off-by: Tycho Andersen (AMD) <tycho@kernel.org>\nAcked-by: Herbert Xu <herbert@gondor.apana.org.au>\nReviewed-by: Tom Lendacky <thomas.lendacky@amd.com>\nTested-by: Tycho Andersen (AMD) <tycho@kernel.org>\nLink: https://patch.msgid.link/20260416232329.3408497-3-seanjc@google.com\nSigned-off-by: Sean Christopherson <seanjc@google.com>"
+    },
     "CVE-2025-38349": {
       "e09c77d940034e3f0c4ae1c18cc655ea9ec2cc41": "eventpoll: hoist CTL_ADD scratch state into struct ep_ctl_ctx\n\nThree globals were shared between the loop check and the path check\npaths: tfile_check_list (chain of epitems_head to walk afterwards),\npath_count[] (per-depth wakeup-path tally) and inserting_into\n(cycle-detection sentinel). All three are scratch state used only\nduring a single EPOLL_CTL_ADD full_check, yet they sit at file\nscope and rely on epnested_mutex for exclusion.\n\nThe area has had three bugs in the last year -- CVE-2025-38349,\nf2e467a48287 (\"eventpoll: Fix semi-unbounded recursion\"), and\nfdcfce93073d (\"eventpoll: Fix integer overflow in\nep_loop_check_proc()\") -- all rooted in the shared-mutable-global\npattern being hard to reason about.\n\nCollect the three into a stack-allocated struct ep_ctl_ctx:\n\n    struct ep_ctl_ctx {\n        struct eventpoll   *inserting_into;\n        struct epitems_head *tfile_check_list;\n        int                 path_count[PATH_ARR_SIZE];\n    };\n\ndo_epoll_ctl() zero-initializes one on its stack and plumbs it\nthrough ep_ctl_lock() / ep_ctl_unlock() / ep_insert() /\nep_register_epitem() / list_file() / ep_loop_check() /\nep_loop_check_proc() / reverse_path_check() /\nreverse_path_check_proc() / path_count_inc() / path_count_init() /\nclear_tfile_check_list(). Non-nested inserts leave the ctx zeroed\nand skip the machinery entirely.\n\nWith the scratch state in ctx:\n  - tfile_check_list no longer has an EP_UNACTIVE_PTR sentinel --\n    NULL is the obvious \"empty\" value and the zero-init handles it\n    for free;\n  - path_count[] is no longer an array global that could be touched\n    in unexpected orderings;\n  - inserting_into is scoped to the exact call that set it.\n\nloop_check_gen stays as a file-scope monotonic counter, because the\nstamp left on ep->gen by a completed walk must not equal the stamp\nof a future walk -- something a stack-local value cannot guarantee\nacross calls. It remains protected by epnested_mutex for the bump\nand read lockless for the \"do we need a full check\" trigger in\nep_ctl_lock().\n\nEvery bail-out that existed before (the ELOOP on cycle, the path\nlimit check, the unbounded-recursion cap, the +1 overflow guard) is\npreserved verbatim; only the data they operate on moved from file\nscope to the stack ctx.\n\nNo functional change.\n\nSigned-off-by: Christian Brauner (Amutable) <brauner@kernel.org>\nLink: https://patch.msgid.link/20260424-work-epoll-rework-v1-17-249ed00a20f3@kernel.org\nSigned-off-by: Christian Brauner <brauner@kernel.org>",
       "35e7fa083ab25f68c7cd57b9427f65d8794ab7c2": "eventpoll: document loop-check / path-check globals\n\nThe globals that support EPOLL_CTL_ADD's cycle and path-length checks\nare scattered: epnested_mutex, loop_check_gen, inserting_into, and\ntfile_check_list sit at the top of the file; path_count[] and\npath_limits[] are declared inline with the path-check code further\ndown. Their interaction -- the \"ep->gen == loop_check_gen\" trigger in\ndo_epoll_ctl(), the two loop_check_gen++ bumps that sandwich a check,\nthe EP_UNACTIVE_PTR sentinel on tfile_check_list, the -ELOOP back-edge\ndetection via inserting_into -- is not documented anywhere.\n\nThe area has had three recent fixes (CVE-2025-38349, the unbounded\nrecursion fix, and the overflow fix) whose logic depends on these\ninvariants. Collect the description in one block alongside the\ndeclarations, cross-reference the path_count[] declaration that lives\nwith the path-check code, and name the fix commits so future readers\ncan find the context.\n\nAlso add a short comment on struct epitems_head describing its\ndual use (wrapper for non-epoll file->f_ep versus pointing into\n&ep->refs for the epoll-watches-epoll case), which the old comment\non tfile_check_list had accidentally attached to the struct.\n\nComment-only; no functional change.\n\nSigned-off-by: Christian Brauner (Amutable) <brauner@kernel.org>\nLink: https://patch.msgid.link/20260424-work-epoll-rework-v1-2-249ed00a20f3@kernel.org\nSigned-off-by: Christian Brauner <brauner@kernel.org>"