Sync Collecting Fix Commits: Mon Jul 20 22:23:42 UTC 2026

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

Author: aboutcode-automation

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

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/kubernetes/kubernetes",
   "vulnerabilities": {
+    "CVE-2026-33186": {
+      "bf2712d71b395db54097b5ae40f1383fe979e384": "Update google.golang.org/grpc to v1.82.1\n\nThis release fixes three security issues in grpc-go.\n\n- A gRPC server now stops reading from a connection when a peer sends\n  too many HTTP/2 control frames. Before this change, a peer could\n  flood a server with control frames and make it use too much memory\n  and CPU. See grpc/grpc-go#9236. There is no fixed v1.81.x release.\n- The GRPC_GO_EXPERIMENTAL_DISABLE_STRICT_PATH_CHECKING environment\n  variable is removed. Setting it turned strict path checking off and\n  brought back the authorization bypass from CVE-2026-33186.\n- The old gzip Decompressor API now limits how much data it\n  decompresses, so a small compressed message can no longer use an\n  unbounded amount of memory. Kubernetes does not call this API.\n\nThe update does not change any other dependency. Kubernetes already\nrequires newer versions of everything grpc v1.82.1 needs, so the\nvendor changes cover only vendor/google.golang.org/grpc. There are no\nchanges to hack/unwanted-dependencies.json or LICENSES."
+    },
     "CVE-2026-33814": {
       "12a2470693d86f63f4614048ffdd43dc393dd7e0": "Update golang.org/x/net to v0.53.0\n\nFixes CVE-2026-33814 (golang/go#78476): HTTP/2 Transport hangs\nindefinitely when a peer sends a SETTINGS frame with MaxFrameSize=0.\nThis is reachable from kube-apiserver's OIDC, admission webhook,\nand aggregated API client paths."
     },

data/fix-commits/common-dd5d765c.json

@@ -67,8 +67,7 @@
       "24376458138387fb251e782e624c7776e9826796": "isofs: validate block number from NFS file handle in isofs_export_iget\n\nisofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker-\ncontrolled block number (ifid->block or ifid->parent_block) from\nthe NFS file handle to isofs_export_iget(), which only rejects\nblock == 0 before calling isofs_iget() and ultimately sb_bread().\nA crafted file handle with fh_len sufficient to pass the check\nadded by commit 0405d4b63d08 (\"isofs: Prevent the use of too small\nfid\") can still drive the server to read any in-range block on the\nbacking device as if it were an iso_directory_record.  That earlier\nfix was assigned CVE-2025-37780.\n\nsb_bread() on an out-of-range block returns NULL cleanly via the\nEIO path, so there is no memory-safety violation.  For in-range\nreads of adjacent-partition data on the same block device, the\nunrelated bytes end up in iso_inode_info fields that reach the NFS\nclient as dentry metadata.  The deployment surface (isofs exported\nover NFS from loop-mounted images) is narrow and requires an\nauthenticated NFS peer, but the malformed-file-handle class is\nreportable as hardening next to the existing CVE-2025-37780 fix.\n\nReject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so\nthe check covers both isofs_fh_to_dentry() and isofs_fh_to_parent()\ncall sites with a single line.\n\nFixes: 0405d4b63d08 (\"isofs: Prevent the use of too small fid\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-4-7\nSigned-off-by: Michael Bommarito <michael.bommarito@gmail.com>\nLink: https://patch.msgid.link/20260419212155.2169382-3-michael.bommarito@gmail.com\nSigned-off-by: Jan Kara <jack@suse.cz>"
     },
     "CVE-2026-0995": {
-      "858fbd7248bd84b2899fb2c29bc7bc2634296edf": "Merge branch 'for-next/c1-pro-erratum-4193714' into for-next/core\n\n* for-next/c1-pro-erratum-4193714:\n  : Work around C1-Pro erratum 4193714 (CVE-2026-0995)\n  arm64: errata: Work around early CME DVMSync acknowledgement\n  arm64: cputype: Add C1-Pro definitions\n  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()\n  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance",
-      "cfb66b49676ef3a4ed0bf047ffdf7014d1d04a4c": "Merge branch 'for-next/c1-pro-erratum-4193714' into for-next/core\n\n* for-next/c1-pro-erratum-4193714:\n  : Work around C1-Pro erratum 4193714 (CVE-2026-0995)\n  arm64: errata: Work around early CME DVMSync acknowledgement\n  arm64: cputype: Add C1-Pro definitions\n  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()\n  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance"
+      "858fbd7248bd84b2899fb2c29bc7bc2634296edf": "Merge branch 'for-next/c1-pro-erratum-4193714' into for-next/core\n\n* for-next/c1-pro-erratum-4193714:\n  : Work around C1-Pro erratum 4193714 (CVE-2026-0995)\n  arm64: errata: Work around early CME DVMSync acknowledgement\n  arm64: cputype: Add C1-Pro definitions\n  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()\n  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance"
     },
     "CVE-2026-23234": {
       "39d4ee19c1e7d753dd655aebee632271b171f43a": "f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io()\n\nIn f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bring\nthe F2FS_WB_CP_DATA counter to zero, unblocking\nf2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmount\nCPU. The unmount path then proceeds to call\nf2fs_destroy_page_array_cache(sbi), which destroys\nsbi->page_array_slab via kmem_cache_destroy(), and eventually\nkfree(sbi). Meanwhile, the bio completion callback is still executing:\nwhen it reaches page_array_free(sbi, ...), it dereferences\nsbi->page_array_slab \u2014 a destroyed slab cache \u2014 to call\nkmem_cache_free(), causing a use-after-free.\n\nThis is the same class of bug as CVE-2026-23234 (which fixed the\nequivalent race in f2fs_write_end_io() in data.c), but in the\ncompressed writeback completion path that was not covered by that fix.\n\nFix this by moving dec_page_count() to after page_array_free(), so\nthat all sbi accesses complete before the counter decrement that can\nunblock unmount. For non-last folios (where atomic_dec_return on\ncic->pending_pages is nonzero), dec_page_count is called immediately\nbefore returning \u2014 page_array_free is not reached on this path, so\nthere is no post-decrement sbi access. For the last folio,\npage_array_free runs while the F2FS_WB_CP_DATA counter is still\nnonzero (this folio has not yet decremented it), keeping sbi alive,\nand dec_page_count runs as the final operation.\n\nFixes: 4c8ff7095bef (\"f2fs: support data compression\")\nCc: stable@vger.kernel.org\nSigned-off-by: George Saad <geoo115@gmail.com>\nReviewed-by: Chao Yu <chao@kernel.org>\nSigned-off-by: Jaegeuk Kim <jaegeuk@kernel.org>"

data/fix-commits/git-e83ef8ed.json

@@ -1,6 +1,16 @@
 {
   "vcs_url": "https://github.com/nixos/nixpkgs",
   "vulnerabilities": {
+    "CVE-2026-5090": {
+      "4ff38198b478c7c2486a932e8564f6b365855c56": "perlPackages.TemplateToolkit: 3.101 -> 3.106\n\nThis release includes the fix for CVE-2026-5090.\n\nAssisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)\n(cherry picked from commit 1dab000f41ba92a128575356ec6d9febcb8e498b)",
+      "1dab000f41ba92a128575356ec6d9febcb8e498b": "perlPackages.TemplateToolkit: 3.101 -> 3.106\n\nThis release includes the fix for CVE-2026-5090.\n\nAssisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)"
+    },
+    "CVE-2026-14476": {
+      "16f24194a812a22884c304cff107aaac1683633b": "[Backport release-26.05] sssd: patch CVE-2026-14476 (#543834)",
+      "ca3498b029825663f5f0b65cf5cba78eaa78fcd4": "sssd: patch CVE-2026-14476\n\nBackport the upstream 2.13 fix that rejects path traversal in gPCFileSysPath before GPO cache paths are constructed.\n\nAssisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)\n(cherry picked from commit ee4b7e100e8842d83a20fc52d12b8cc3ad827804)",
+      "ebcedbcc64ffc14d0b22b979c626bca55c6ec155": "sssd: patch CVE-2026-14476 (#543769)",
+      "ee4b7e100e8842d83a20fc52d12b8cc3ad827804": "sssd: patch CVE-2026-14476\n\nBackport the upstream 2.13 fix that rejects path traversal in gPCFileSysPath before GPO cache paths are constructed.\n\nAssisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)"
+    },
     "CVE-2026-58447": {
       "2d86cdb005a9d59c19f82f7458e95edb66f3e34c": "[Backport release-26.05] invidious: patch CVE-2026-58447 (#543606)",
       "a9855787eea2f8cb87b225a07c35ccd36aee43fe": "invidious: patch CVE-2026-58447\n\nhttps://github.com/iv-org/invidious/commit/77ad41678b45c4f6815940123f1796fc51259f45\n\nhttps://tracker.security.nixos.org/suggestions/by-id/10419/\n\nAssisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)\n(cherry picked from commit 4c54c8b8794c7a32970827d34d61974464a03bcf)",

data/fix-commits/kubernetes-dd5bb6b7.json

@@ -1,6 +1,15 @@
 {
   "vcs_url": "https://gitlab.com/qemu-project/qemu",
   "vulnerabilities": {
+    "CVE-2026-16043": {
+      "cc479aa89743655a725ce29328bcd0585a65983a": "hw/usb/hcd-xhci-sysbus: Fix OOB heap access in xhci_sysbus_intr_raise()\n\nSome machines like the microvm machine instantiate a \"sysbus-xhci\"\ndevice with just 1 interrupt (by setting the \"intrs\" property to 1).\nxhci_sysbus_realize() then only allocates the s->irq array with one\nentry.\n\nWhen the guest writes to the ERDP register of a corresponding XHCI\n\"interrupter\", the generic XHCI code calls the xhci_sysbus_intr_raise()\nfunction with n > 1, and this function then calls qemu_set_irq() with\ns->irq[n] pointing to a bad heap address. The qemu_set_irq() then tries\nto call an IRQ handler via a function pointer in that heap space. This\neither causes QEMU to die with a segmentation fault (if it's a bad\naddress), or even worse runs some unexpected code if the destination\nof the pointer is executable code.\n\nLooking at the xHCI spec, it is up to the implementation of the host\ncontroller how many interrupters are available. So if we only support\none or some few interrupters, the registers of the other interrupters\nshould not do anything, i.e. reads should result in zeros and writes\nshould be completely ignored. (big thanks to Peter Maydell for helping\nwith the analyzation of the correct way to fix this here)\n\nThis way, the xhci_sysbus_intr_raise() function cannot be called with\nan invalid interrupt number anymore. But for good measure, also add an\nassert() statement to the xhci_sysbus_intr_raise() function to prevent\nthat similar problems with calling arbitrary function pointers on the\nheap could occur again.\n\nFixes: CVE-2026-16043\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/4001\nReported-by: Tristan Madani <tristan@talencesecurity.com>\nReviewed-by: Peter Maydell <peter.maydell@linaro.org>\nSigned-off-by: Thomas Huth <thuth@redhat.com>\nMessage-ID: <20260719061528.15587-1-thuth@redhat.com>"
+    },
+    "CVE-2026-63319": {
+      "a002485bfef184f04a58adfd2a848c19f583f7d0": "usbredir: fix infinite loop and SIGFPE with zero max_packet_size\n\nA malicious usbredir peer can send an ep_info message resetting\nmax_packet_size to 0 after bulk receiving has started. This causes:\n- infinite loop in usbredir_buffered_bulk_packet() where the splitting\n  loop increments by max_packet_size (0)\n- SIGFPE in usbredir_buffered_bulk_in_complete_ftdi() from modulo by 0\n- SIGFPE in usbredir_handle_buffered_bulk_in_data() from division by 0\n  when computing bytes_per_transfer\n\nFix by stopping and disabling bulk receiving in usbredir_ep_info() when\nmax_packet_size is set to 0.\n\nAdd post-load check, and assert() for the invariant.\n\nFixes: CVE-2026-63319\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3995\nReported-by: Tristan @TristanInSec\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>\nReviewed-by: Thomas Huth <thuth@redhat.com>\nMessage-ID: <20260716141107.3597076-1-marcandre.lureau@redhat.com>\nSigned-off-by: Thomas Huth <thuth@redhat.com>"
+    },
+    "CVE-2026-15705": {
+      "9bf52d056a03cd3768caccbc4c88fcc34be26c28": "usbredir: fix use-after-free on buffered bulk packet overflow\n\nWhen usbredir_buffered_bulk_packet() splits a multi-fragment buffered\nbulk packet into max-packet-size chunks, only the final fragment owns\nthe shared parser allocation (via free_on_destroy). If bufp_alloc()\ndrops the final fragment due to queue overflow, it frees the backing\nbuffer while earlier fragments already queued still hold interior\npointers into it. Subsequent guest bulk-IN transfers then read from\nfreed heap memory.\n\nFix this by tracking how many fragments were queued during the current\npacket. When bufp_alloc() fails, remove all already-queued fragments\nfrom the tail of the endpoint queue before breaking out of the loop.\nIf the dropped fragment was non-final, free the data buffer explicitly\nsince no fragment took ownership.\n\nFixes: CVE-2026-15705\nFixes: b2d1fe67d09d (\"usbredir: Add support for buffered bulk input (v2)\")\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3808\nReported-by: Feifan Qian <bea1e@proton.me>\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>\nMessage-ID: <20260714185717.1156157-1-marcandre.lureau@redhat.com>\nSigned-off-by: Thomas Huth <thuth@redhat.com>"
+    },
     "CVE-2026-63109": {
       "861372428b05f74a1cf9a8af22a863aa7b46c7ce": "hw/display/virtio-gpu: validate stride against width on scanout\n\nValidate that the framebuffer stride is at least width * bytes_per_pixel\nin both virtio_gpu_scanout_blob_to_fb() and virtio_gpu_do_set_scanout().\n\nA guest can set a very small stride while using a large width. The total\nsize check (offset + stride * height <= blob_size) passes because\nstride * height is small, but pixman reads width * bytes_per_pixel per\nrow, causing heap OOB reads. The leaked data is rendered to the host\ndisplay.\n\nThe check is added in virtio_gpu_do_set_scanout() to cover all paths:\nblob scanout, non-blob scanout and migration post_load. The additional\nearly check in virtio_gpu_scanout_blob_to_fb() rejects invalid blob\nconfigurations early.\n\nFixes: CVE-2026-63109\nFixes: 7b5574225429 (\"hw/display: check frame buffer can hold blob\")\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3989\nReported-by: Tristan @TristanInSec\nReviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>"
     },

data/fix-commits/linux-next.git-786af98a.json

@@ -1,6 +1,15 @@
 {
   "vcs_url": "https://github.com/qemu/qemu",
   "vulnerabilities": {
+    "CVE-2026-16043": {
+      "cc479aa89743655a725ce29328bcd0585a65983a": "hw/usb/hcd-xhci-sysbus: Fix OOB heap access in xhci_sysbus_intr_raise()\n\nSome machines like the microvm machine instantiate a \"sysbus-xhci\"\ndevice with just 1 interrupt (by setting the \"intrs\" property to 1).\nxhci_sysbus_realize() then only allocates the s->irq array with one\nentry.\n\nWhen the guest writes to the ERDP register of a corresponding XHCI\n\"interrupter\", the generic XHCI code calls the xhci_sysbus_intr_raise()\nfunction with n > 1, and this function then calls qemu_set_irq() with\ns->irq[n] pointing to a bad heap address. The qemu_set_irq() then tries\nto call an IRQ handler via a function pointer in that heap space. This\neither causes QEMU to die with a segmentation fault (if it's a bad\naddress), or even worse runs some unexpected code if the destination\nof the pointer is executable code.\n\nLooking at the xHCI spec, it is up to the implementation of the host\ncontroller how many interrupters are available. So if we only support\none or some few interrupters, the registers of the other interrupters\nshould not do anything, i.e. reads should result in zeros and writes\nshould be completely ignored. (big thanks to Peter Maydell for helping\nwith the analyzation of the correct way to fix this here)\n\nThis way, the xhci_sysbus_intr_raise() function cannot be called with\nan invalid interrupt number anymore. But for good measure, also add an\nassert() statement to the xhci_sysbus_intr_raise() function to prevent\nthat similar problems with calling arbitrary function pointers on the\nheap could occur again.\n\nFixes: CVE-2026-16043\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/4001\nReported-by: Tristan Madani <tristan@talencesecurity.com>\nReviewed-by: Peter Maydell <peter.maydell@linaro.org>\nSigned-off-by: Thomas Huth <thuth@redhat.com>\nMessage-ID: <20260719061528.15587-1-thuth@redhat.com>"
+    },
+    "CVE-2026-63319": {
+      "a002485bfef184f04a58adfd2a848c19f583f7d0": "usbredir: fix infinite loop and SIGFPE with zero max_packet_size\n\nA malicious usbredir peer can send an ep_info message resetting\nmax_packet_size to 0 after bulk receiving has started. This causes:\n- infinite loop in usbredir_buffered_bulk_packet() where the splitting\n  loop increments by max_packet_size (0)\n- SIGFPE in usbredir_buffered_bulk_in_complete_ftdi() from modulo by 0\n- SIGFPE in usbredir_handle_buffered_bulk_in_data() from division by 0\n  when computing bytes_per_transfer\n\nFix by stopping and disabling bulk receiving in usbredir_ep_info() when\nmax_packet_size is set to 0.\n\nAdd post-load check, and assert() for the invariant.\n\nFixes: CVE-2026-63319\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3995\nReported-by: Tristan @TristanInSec\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>\nReviewed-by: Thomas Huth <thuth@redhat.com>\nMessage-ID: <20260716141107.3597076-1-marcandre.lureau@redhat.com>\nSigned-off-by: Thomas Huth <thuth@redhat.com>"
+    },
+    "CVE-2026-15705": {
+      "9bf52d056a03cd3768caccbc4c88fcc34be26c28": "usbredir: fix use-after-free on buffered bulk packet overflow\n\nWhen usbredir_buffered_bulk_packet() splits a multi-fragment buffered\nbulk packet into max-packet-size chunks, only the final fragment owns\nthe shared parser allocation (via free_on_destroy). If bufp_alloc()\ndrops the final fragment due to queue overflow, it frees the backing\nbuffer while earlier fragments already queued still hold interior\npointers into it. Subsequent guest bulk-IN transfers then read from\nfreed heap memory.\n\nFix this by tracking how many fragments were queued during the current\npacket. When bufp_alloc() fails, remove all already-queued fragments\nfrom the tail of the endpoint queue before breaking out of the loop.\nIf the dropped fragment was non-final, free the data buffer explicitly\nsince no fragment took ownership.\n\nFixes: CVE-2026-15705\nFixes: b2d1fe67d09d (\"usbredir: Add support for buffered bulk input (v2)\")\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3808\nReported-by: Feifan Qian <bea1e@proton.me>\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>\nMessage-ID: <20260714185717.1156157-1-marcandre.lureau@redhat.com>\nSigned-off-by: Thomas Huth <thuth@redhat.com>"
+    },
     "CVE-2026-63109": {
       "861372428b05f74a1cf9a8af22a863aa7b46c7ce": "hw/display/virtio-gpu: validate stride against width on scanout\n\nValidate that the framebuffer stride is at least width * bytes_per_pixel\nin both virtio_gpu_scanout_blob_to_fb() and virtio_gpu_do_set_scanout().\n\nA guest can set a very small stride while using a large width. The total\nsize check (offset + stride * height <= blob_size) passes because\nstride * height is small, but pixman reads width * bytes_per_pixel per\nrow, causing heap OOB reads. The leaked data is rendered to the host\ndisplay.\n\nThe check is added in virtio_gpu_do_set_scanout() to cover all paths:\nblob scanout, non-blob scanout and migration post_load. The additional\nearly check in virtio_gpu_scanout_blob_to_fb() rejects invalid blob\nconfigurations early.\n\nFixes: CVE-2026-63109\nFixes: 7b5574225429 (\"hw/display: check frame buffer can hold blob\")\nResolves: https://gitlab.com/qemu-project/qemu/-/work_items/3989\nReported-by: Tristan @TristanInSec\nReviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>\nSigned-off-by: Marc-Andr\u00e9 Lureau <marcandre.lureau@redhat.com>"
     },