Sync Collecting Fix Commits: Thu May 21 08:19:10 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/imagemagick/imagemagick",
   "vulnerabilities": {
+    "GHSA-GM48-C7F2-V67P": {
+      "3705205e1424d379c2fc46c026c8560ccea0509e": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-gm48-c7f2-v67p"
+    },
     "GHSA-H36C-3666-H489": {
       "9ee821731faee8c4cc44103cc4180854046bb13c": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-h36c-3666-h489"
     },

data/fix-commits/imagemagick-b15feb65.json

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/imagemagick/imagemagick6",
   "vulnerabilities": {
+    "GHSA-GM48-C7F2-V67P": {
+      "a2aa44ce71f0950522a104bbd4daa7b8a0b6709c": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-gm48-c7f2-v67p"
+    },
     "GHSA-H36C-3666-H489": {
       "60153856299c66689e3620b8347c0cc32c807d95": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-h36c-3666-h489"
     },

data/fix-commits/imagemagick6-19533b67.json

@@ -1,6 +1,14 @@
 {
   "vcs_url": "https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git",
   "vulnerabilities": {
+    "CVE-2026-43500": {
+      "7769d17e023a3aa4b4bc5b700532004c8d701962": "Merge branch 'rxrpc-better-fix-for-data-response-decrypt-vs-splice'\n\nDavid Howells says:\n\n====================\nrxrpc: Better fix for DATA/RESPONSE decrypt vs splice()\n\nHere are two patches containing better fixes for the in-place decryption of\nDATA and RESPONSE packets that can corrupt pagecache spliced into UDP\npackets and sent to an AF_RXRPC server [CVE-2026-43500], plus a patch to\nprecheck the length of rxgk-secured DATA packets.\n\nOf the main patches, one patch fixes DATA decryption by having recvmsg\nunconditionally extract the data into a flat bounce buffer and, if need be,\ndecrypt it there.  It doesn't seem to cause a performance problem to do\nthis even on unencrypted packets; for encrypted packets it makes sure the\ncontent is correctly aligned for crypto which seems to get a small\nperformance gain.\n\nFurther, it means that DATA packets are no longer copied in the I/O thread,\navoiding a slowdown of the protocol engine that runs there.\n\nThe other main patch fixes RESPONSE decryption by having the connection\nevent handler worker copy the data to a flat buffer and, again, decrypt it\nthere.  This simplifies RESPONSE handling.\n\nWith these two fixes, the data content of the received sk_buff no longer\ngets altered.\n====================\n\nLink: https://patch.msgid.link/20260515230516.2718212-1-dhowells@redhat.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>",
+      "8bfab4b6ffc2fe92da86300728fc8c3c7ebffb56": "rxrpc: Fix RESPONSE packet verification to extract skb to a linear buffer\n\nThis improves the fix for CVE-2026-43500.\n\nFix the verification of RESPONSE packets to avoid the problem of\noverwriting a RESPONSE packet sent via splice to a local address by\nextracting the contents of the UDP packet into a kmalloc'd linear buffer\nrather than decrypting the data in place in the sk_buff (which may corrupt\nthe original buffer).\n\nFixes: 24481a7f5733 (\"rxrpc: Fix conn-level packet handling to unshare RESPONSE packets\")\nReported-by: Hyunwoo Kim <imv4bel@gmail.com>\nCloses: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/\nSigned-off-by: David Howells <dhowells@redhat.com>\ncc: Simon Horman <horms@kernel.org>\ncc: Jiayuan Chen <jiayuan.chen@linux.dev>\ncc: linux-afs@lists.infradead.org\ncc: stable@kernel.org\nReviewed-by: Jeffrey Altman <jaltman@auristor.com>\nTested-by: Marc Dionne <marc.dionne@auristor.com>\nLink: https://patch.msgid.link/20260515230516.2718212-4-dhowells@redhat.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>",
+      "d2bc90cf6c75cb96d2ce549be6c35efa3099d25b": "rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg\n\nThis improves the fix for CVE-2026-43500.\n\nFix the pagecache corruption from in-place decryption of a DATA packet\ntransmitted locally by splice() by getting rid of the packet sharing in the\nI/O thread and unconditionally extracting the packet content into a bounce\nbuffer in which the buffer is decrypted.  recvmsg() (or the kernel\nequivalent) then copies the data from the bounce buffer to the destination\nbuffer.  The sk_buff then remains unmodified.\n\nThis has an additional advantage in that the packet is then arranged in the\nbuffer with the correct alignment required for the crypto algorithms to\nprocess directly.  The performance of the crypto does seem to be a little\nfaster and, surprisingly, the unencrypted performance doesn't seem to\nchange much - possibly due to removing complexity from the I/O thread.\n\nYet another advantage is that the I/O thread doesn't have to copy packets\nwhich would slow down packet distribution, ACK generation, etc..\n\nThe buffer belongs to the call and is allocated initially at 2K,\nsufficiently large to hold a whole jumbo subpacket, but the buffer will be\nincreased in size if needed.  However, to take this work, MSG_PEEK may\ncause a later packet to be decrypted into the buffer, in which case the\nearlier one will need re-decrypting for a subsequent recvmsg().\n\nNote that rx_pkt_offset may legitimately see 0 as a valid offset now, so\nswitch to using USHRT_MAX to indicate an invalid offset.\n\nNote also that I would generally prefer to replace the buffers of the\ncurrent sk_buff with a new kmalloc'd buffer of the right size, ditching the\nold data and frags as this makes the handling of MSG_PEEK easier and\nremoves the re-decryption issue, but this looks like quite a complicated\nthing to achieve.  skb_morph() looks half way to what I want, but I don't\nwant to have to allocate a new sk_buff.\n\nFixes: d0d5c0cd1e71 (\"rxrpc: Use skb_unshare() rather than skb_cow_data()\")\nReported-by: Hyunwoo Kim <imv4bel@gmail.com>\nCloses: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/\nSigned-off-by: David Howells <dhowells@redhat.com>\ncc: Simon Horman <horms@kernel.org>\ncc: Jiayuan Chen <jiayuan.chen@linux.dev>\ncc: linux-afs@lists.infradead.org\nReviewed-by: Jeffrey Altman <jaltman@auristor.com>\nTested-by: Marc Dionne <marc.dionne@auristor.com>\nLink: https://patch.msgid.link/20260515230516.2718212-3-dhowells@redhat.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>"
+    },
+    "CVE-2025-39860": {
+      "ab1513597c6cf17cd1ad2a21e3b045421b48e022": "Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()\n\nbt_accept_dequeue() unlinks a not-yet-accepted child from the parent\naccept queue and release_sock()s it before returning, so the returned\nsk has no caller reference and is unlocked.\n\nl2cap_sock_cleanup_listen() walks these children on listening-socket\nclose.  A concurrent HCI disconnect drives hci_rx_work ->\nl2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and\nfrees the child sk and its l2cap_chan; cleanup_listen() then uses both:\n\n  BUG: KASAN: slab-use-after-free in l2cap_sock_kill\n    l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close\n  Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill\n\nThis is distinct from the two fixes already in this area: commit\ne83f5e24da741 (\"Bluetooth: serialize accept_q access\") serialises the\naccept_q list/poll and takes temporary refs inside bt_accept_dequeue(),\nand CVE-2025-39860 serialises the userspace close()/accept() race by\ncalling cleanup_listen() under lock_sock() in l2cap_sock_release().\nNeither covers l2cap_conn_del() running from hci_rx_work, so this UAF\nstill reproduces on current bluetooth/master.\n\nTake the reference at the source: bt_accept_dequeue() does sock_hold()\nwhile sk is still locked, before release_sock(); callers sock_put().\ncleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under\na brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops\nit before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on\nSOCK_DEAD.  conn->lock is not taken here: cleanup_listen() runs under\nthe parent sk lock and that would invert\nconn->lock -> chan->lock -> sk_lock (lockdep).\n\nKASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced\n12 use-after-free reports per run before this change; 0, and no lockdep\nreport, over 1600+ raced iterations after it on bluetooth/master.\n\nFixes: 15f02b910562 (\"Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode\")\nCc: stable@vger.kernel.org\nReported-by: Siwei Zhang <oss@fourdim.xyz>\nReviewed-by: Siwei Zhang <oss@fourdim.xyz>\nSigned-off-by: Safa Karaku\u015f <safa.karakus@secunnix.com>\nSigned-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>"
+    },
     "CVE-2023-20585": {
       "1f44aab79bac31f459422dfb213e907bb386509c": "iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19\n\nDue to CVE-2023-20585, the PPR log buffer must use the maximum supported\nsize (512K) on Genoa (Family 0x19, model >= 0x10) systems when SNP is\nenabled, to mitigate a potential security vulnerability. Note that Family\n0x19 models below 0x10 (Milan) do not support PPR when SNP is enabled.\nHence the PPR log size increase is only applied for model >= 0x10.\nAll other systems continue to use the default PPR log buffer size (8K).\n\nApply the errata fix by making the following changes:\n\n- Introduce global new variable (amd_iommu_pprlog_size) to have PPR log buffer\n  size. Adjust variable size for Genoa family.\n\n- Extend 'amd_iommu_apply_erratum_snp()' to also set the PPR log buffer\n  size to maximum for Family 0x19 model >= 0x10 when SNP is enabled.\n\n- Rename PPR_* macros to make it more readable.\n\nLink: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html\nCc: Borislav Petkov <bp@alien8.de>\nCc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>\nCc: Joerg Roedel <joerg.roedel@amd.com>\nSigned-off-by: Vasant Hegde <vasant.hegde@amd.com>\nTested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>\nSigned-off-by: Joerg Roedel <joerg.roedel@amd.com>",
       "58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f": "iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19\n\nDue to CVE-2023-20585, the Event log buffer must use the maximum supported\nsize (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled,\nto mitigate a potential security vulnerability. All other systems continue to\nuse the default Event log buffer size (8K).\n\nApply the errata fix by making the following changes:\n\n* Introduce new global variable (amd_iommu_evtlog_size) to have event log\n  buffer size. Adjust variable size for family 0x19.\n\n* Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem\n  is initialized, it cannot be moved to the early init stage. The SNP errata\n  must also be applied after the 'iommu_snp_enable()' check. Therefore,\n  'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called\n  in the IOMMU_ENABLED state, after the errata is applied.\n\n* Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle\n  all IOMMU instances.\n\n* Also rename EVT_* macros to make it more readable.\n\nLink: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html\nCc: Borislav Petkov <bp@alien8.de>\nCc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>\nCc: Joerg Roedel <joerg.roedel@amd.com>\nSigned-off-by: Vasant Hegde <vasant.hegde@amd.com>\nTested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>\nSigned-off-by: Joerg Roedel <joerg.roedel@amd.com>"