Sync Collecting Fix Commits: Tue Sep 8 23:32:25 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://android.googlesource.com/platform/frameworks/base",
   "vulnerabilities": {
+    "CVE-2025-22442": {
+      "79dd06a8c17c5e5b8a5a22b4f8819a5c8c263011": "CVE-2025-22442: set profile user restrictions earlier\n\nBug: 382064697\nFlag: EXEMPT BUGFIX\nCherrypick-From: https://googleplex-android-review.googlesource.com/q/commit:994366d40c9519f00a9a67c554f7b459ebf587ee\nCherrypick-From: https://googleplex-android-review.googlesource.com/q/commit:0821e223d2d989c7c3b3820faa063e982aed6dc7\nMerged-In: I9019c05f61455feb1ce03d0dd8818a6f13c7af97\nChange-Id: I9019c05f61455feb1ce03d0dd8818a6f13c7af97"
+    },
     "CVE-2025-48525": {
       "bde20ba16ceac713395a347a8a0fd18d3b7792b3": "Revert \"[CDM] Revoke NLS when all associations are removed.\"\n\nThis reverts commit a987e9d91a93b5945ac7d6477e6d34cd2715f2ec.\n\nReason for revert: CVE-2025-48525 A-391895151 is being removed from ASB#2025-09 due to a possible regression that may prevent Android Auto projection to launch properly. Partners are recommended to remove this fix until the updated fix is available.\n\nBug: 391895151\n(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:cd108837baa0008e53f93eba3208db56a0499bb0)\nMerged-In: I648f49c7413afebf46409806a90db2576b5ef5af\nChange-Id: I648f49c7413afebf46409806a90db2576b5ef5af"
     },

data/fix-commits/base-9ee096e2.json

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://git.kernel.org/pub/scm/bluetooth/bluez.git",
   "vulnerabilities": {
+    "GHSA-M2VX-PW5F-RC8V": {
+      "b21c216d580cf303681bfe9eab60a5414d8b6cc0": "avrcp: Fix out-of-bounds parsing of ListPlayerAttributes response\n\nIn profiles/audio/avrcp.c, avrcp_list_player_attributes_rsp() parsed the\nresponse using hand-computed offsets into the operands buffer, without\naccounting for the fact that operand_count spans the 7 byte AVRCP header\nas well as the parameters:\n\n- attrs is a 4 byte array which could be written out-of-bounds if a\n  length greater than 4 was declared in the first parameter byte.\n\n- The attribute bytes were read with a bound derived from operand_count,\n  so a truncated response could be read past its end. As the receive\n  buffer is reused across packets, those stale bytes could be echoed\n  back to the peer in the following GetCurrentPlayerValue request.\n\n- params_len was compared against count, which was only ever 0 at that\n  point, so the length of the PDU was in practice never validated.\n\nParse the response through a struct iovec using the util_iov_pull_*\nhelpers instead, so that the header and each subsequent field are bounds\nchecked as they are consumed and the remaining length is tracked for us.\nThis lets params_len be validated against the actual number of parameter\nbytes received. The attribute count is still clamped to\nAVRCP_ATTRIBUTE_LAST, which is what bounds the write into attrs.\n\nReported-by: @ax-nnlabs\nCloses: https://github.com/bluez/bluez/security/advisories/GHSA-m2vx-pw5f-rc8v\nReported-by: @ax-nnlabs"
+    },
     "GHSA-7WJJ-8MRM-JHW4": {
       "3c18444ced8e40067a855560d6fc18cda21efaba": "bass: Fix heap buffer overflow allocating subgroup_data array\n\nbass_build_bcast_src() in src/shared/bass.c parses the Broadcast Receive State\ncharacteristic value received from a remote BASS server.\n\nIt reads an attacker-controlled num_subgroups byte (range 0-255) but always\nallocates a single bt_bass_subgroup_data entry (24 bytes):\nsubgroup_data = new0(struct bt_bass_subgroup_data, 1);   // line 337: always 1\nfor (int i = 0; i < num_subgroups; i++) {                // line 343: up to 255\n    subgroup_data[i].bis_sync = bis_sync_state;          // line 355: OOB write\n\nReported-by: @thaidn and @bronson-calif of Calif.io in collaboration\n with Claude and Anthropic Research\nSuggested-by: @trace37labs for the Fixes\n\nFixes: 8980f4f1f7 (\"shared/bass: Functions cleanup\")\n\nSee: https://github.com/bluez/bluez/security/advisories/GHSA-7wjj-8mrm-jhw4\nReported-by: @thaidn and @bronson-calif of Calif.io in collaboration"
     },

data/fix-commits/bluez.git-bf64ccd9.json

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/kubernetes/client-go",
   "vulnerabilities": {
+    "CVE-2026-78662": {
+      "bd33a045e7a26a42e6ff40cdfe0ad124cbdbbe6b": "Merge pull request #141886 from AboEl3iz/fix-cve-2026-78662\n\nupdate golang.org/x/crypto to v0.56.0\n\nKubernetes-commit: 7abbc3e0709aa029b8209e2dae5b031f30ac5390"
+    },
     "CVE-2026-33814": {
       "e584095d8287628ded0767fa0bc0263143a87ea2": "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.\n\nKubernetes-commit: 12a2470693d86f63f4614048ffdd43dc393dd7e0"
     },

data/fix-commits/camel-36fc325a.json

@@ -1,6 +1,11 @@
 {
   "vcs_url": "https://github.com/FFmpeg/FFmpeg",
   "vulnerabilities": {
+    "CVE-2025-1594": {
+      "ba69be84a1ceabfb39127831ad8da0fd7cb471f3": "avcodec/aacenc_tns: fix three-filter energy measurement\n\nBackport of bedfb6eca402037f5cbb115fa767d106b8c14f1c to release/6.0.\n\nAAC Main can select three TNS filters, but the old direction calculation only allocates two energy measurements and reads beyond that array for the third filter. Measure all three regions and compare each filter with the following region.\n\nFixes: CVE-2025-1594\nFixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22696\nFound-by: 0x20z\nSigned-off-by: lizhixuan.HUST <2069360659@qq.com>\nAssisted-by: Fairy",
+      "64626725c36c2c0e449ae63381587c35552d2d2f": "avcodec/aacenc_tns: fix three-filter energy measurement\n\nBackport of bedfb6eca402037f5cbb115fa767d106b8c14f1c to release/5.0.\n\nAAC Main can select three TNS filters, but the old direction calculation only allocates two energy measurements and reads beyond that array for the third filter. Measure all three regions and compare each filter with the following region.\n\nFixes: CVE-2025-1594\nFixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22696\nFound-by: 0x20z\nSigned-off-by: lizhixuan.HUST <2069360659@qq.com>\nAssisted-by: Fairy",
+      "0ef8ce13b802d79e3af92861b5dbcc73fc078224": "aacenc_tns: clamp filter direction energy measurement\n\nThe issue is that:\n\nfloat en[2];\n...\ntns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;\nfor (g = 0; g < tns->n_filt[w]; g++) {\n    tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];\n\nWhen using the AAC Main profile, n_filt = 3, and slant is by\ndefault 2 (normal long frames), g can go above 1.\n\nen is the evolution of energy in the frequency domain for every\nband at the given window. E.g. whether the energy is concentrated\nat the top of each band, or the bottom.\n\nFor 2-pole filters, its straightforward.\nFor 3-pole filters, we need more than 2 measurements.\n\nThis commit properly implements support for 3-pole filters, by measuring\nthe band energy across three areas.\n\nDo note that even xHE-AAC caps n_filt to 2, and only AAC Main allows\nn_filt == 3.\n\nFixes https://trac.ffmpeg.org/ticket/11418\n\nFixes: CVE-2025-1594\n\n(cherry picked from commit ed09aa28ae3b4509f00a24a9ebdeb084ee00736a)\n(cherry picked from commit f98f142da571653436596ccad2d09c7e39bfd4fb)\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>\n(cherry picked from commit 21fe514152a22cc5653fd95f065320adfcf076e9)\nSigned-off-by: Carlos Henrique Lima Melara <charlesmelara@riseup.net>"
+    },
     "CVE-2026-30999": {
       "097bc4c44eefb0db2da3bd94185ba72d0842e85b": "tools/zmqsend: free the AVBprint buffer after using it\n\nFixes CVE-2026-30999\n\nFixes: memleak\nFound-by: Xinghang Lv\nSigned-off-by: James Almer <jamrial@gmail.com>\n(cherry picked from commit 144af8f81abc1385631b4e1f4672cd415a9c6e05)\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>",
       "aea4235a81c4925ed74e821e4da4013438856c34": "tools/zmqsend: free the AVBprint buffer after using it\n\nFixes CVE-2026-30999\n\nFixes: memleak\nFound-by: Xinghang Lv\nSigned-off-by: James Almer <jamrial@gmail.com>\n(cherry picked from commit 144af8f81abc1385631b4e1f4672cd415a9c6e05)\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>",
@@ -34,9 +39,6 @@
     "CVE-2025-7700": {
       "01d5c4014319ce804a4eb01359779330f86c45e4": "libavcodec/alsdec.c: Add check for av_malloc_array() and av_calloc()\n\nAdd check for the return value of av_malloc_array() and av_calloc()\nto avoid potential NULL pointer dereference.\n\nBackport comment: In v5.1 and newer, av_calloc is used, but in v4.3 we\nhad av_mallocz_array, but it's susceptible to ENOMEM just the same.\n\nFixes: CVE-2025-7700\n\nFixes: dcfd24b10c (\"avcodec/alsdec: Implement floating point sample data decoding\")\nSigned-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>\n(cherry picked from commit 35a6de137a39f274d5e01ed0e0e6c4f04d0aaf07)\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>\n(cherry picked from commit aad4b59cfee1f0a3cf02f5e2b1f291ce013bf27e)\nSigned-off-by: Carlos Henrique Lima Melara <charlesmelara@riseup.net>"
     },
-    "CVE-2025-1594": {
-      "0ef8ce13b802d79e3af92861b5dbcc73fc078224": "aacenc_tns: clamp filter direction energy measurement\n\nThe issue is that:\n\nfloat en[2];\n...\ntns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;\nfor (g = 0; g < tns->n_filt[w]; g++) {\n    tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];\n\nWhen using the AAC Main profile, n_filt = 3, and slant is by\ndefault 2 (normal long frames), g can go above 1.\n\nen is the evolution of energy in the frequency domain for every\nband at the given window. E.g. whether the energy is concentrated\nat the top of each band, or the bottom.\n\nFor 2-pole filters, its straightforward.\nFor 3-pole filters, we need more than 2 measurements.\n\nThis commit properly implements support for 3-pole filters, by measuring\nthe band energy across three areas.\n\nDo note that even xHE-AAC caps n_filt to 2, and only AAC Main allows\nn_filt == 3.\n\nFixes https://trac.ffmpeg.org/ticket/11418\n\nFixes: CVE-2025-1594\n\n(cherry picked from commit ed09aa28ae3b4509f00a24a9ebdeb084ee00736a)\n(cherry picked from commit f98f142da571653436596ccad2d09c7e39bfd4fb)\nSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>\n(cherry picked from commit 21fe514152a22cc5653fd95f065320adfcf076e9)\nSigned-off-by: Carlos Henrique Lima Melara <charlesmelara@riseup.net>"
-    },
     "CVE-2024-36615": {
       "415ed8bb0936a81737269d8428b55f7cb19f664f": "avcodec/vp9: Fix race when attaching side-data for show-existing frame\n\nWhen outputting a show-existing frame, the VP9 decoder simply\ncreated a reference to said frame and returned it immediately to\nthe caller, without waiting for it to have finished decoding.\nIn case of frame-threading it is possible for the frame to\nonly be decoded while it was waiting to be output.\nThis is normally benign.\n\nBut there is one case where it is not: If the user wants\nvideo encoding parameters to be exported, said side data\nwill only be attached to the src AVFrame at the end of\ndecoding the frame that is actually being shown. Without\nsynchronisation adding said side data in the decoder thread\nand the reads in av_frame_ref() in the output thread\nconstitute a data race. This happens e.g. when using the\nvenc_data_dump tool with vp90-2-10-show-existing-frame.webm\nfrom the FATE-suite.\n\nFix this by actually waiting for the frame to be output.\n\nBackport comment: in 7.1 there was a switch to ProgressFrames\n(7bd3b737163), so there was the need to convert the calls back to\nThreadFrames calls.\n\nFixes: CVE-2024-36615\n\nSigned-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>\n(cherry picked from commit 0ba058579f332b3060d8470a04ddd3fbf305be61)\nSigned-off-by: Carlos Henrique Lima Melara <charlesmelara@riseup.net>"
     },