Skip to content

Commit aca3e82

Browse files
Sync Collecting Fix Commits: Mon Sep 7 02:12:26 UTC 2026
Signed-off-by: AboutCode Automation <automation@aboutcode.org>
1 parent 0744879 commit aca3e82

4 files changed

Lines changed: 191 additions & 9 deletions

File tree

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

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,48 @@
11
{
22
"vcs_url": "https://github.com/github/advisory-database",
33
"vulnerabilities": {
4+
"GHSA-277R-FFRQ-2GVX": {
5+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
6+
},
7+
"GHSA-29Q7-3CRH-JW9H": {
8+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
9+
},
10+
"GHSA-34PG-3X4X-4VF5": {
11+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
12+
},
13+
"GHSA-3W57-W8JF-Q76R": {
14+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
15+
},
16+
"GHSA-74WM-Q835-HXF9": {
17+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
18+
},
19+
"GHSA-CG52-4G45-398G": {
20+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
21+
},
22+
"GHSA-M6GM-QCRR-7GF8": {
23+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
24+
},
25+
"GHSA-QVRV-65V5-745G": {
26+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
27+
},
28+
"GHSA-X2RP-H5QG-FMQG": {
29+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
30+
},
31+
"GHSA-XX33-84GG-2VW9": {
32+
"701dc3ee26c20743607a1649e6c1c28b7341a2c6": "Publish Advisories\n\nGHSA-277r-ffrq-2gvx\nGHSA-29q7-3crh-jw9h\nGHSA-34pg-3x4x-4vf5\nGHSA-3w57-w8jf-q76r\nGHSA-74wm-q835-hxf9\nGHSA-cg52-4g45-398g\nGHSA-m6gm-qcrr-7gf8\nGHSA-qvrv-65v5-745g\nGHSA-x2rp-h5qg-fmqg\nGHSA-xx33-84gg-2vw9"
33+
},
34+
"GHSA-6QM6-V4XP-4RQJ": {
35+
"f6d4e024d0b3b53097cd4716e5db1447892cbbbe": "Publish Advisories\n\nGHSA-6qm6-v4xp-4rqj\nGHSA-7vvx-rvf8-xf4f\nGHSA-86h8-j4jv-gxpx"
36+
},
37+
"GHSA-7VVX-RVF8-XF4F": {
38+
"f6d4e024d0b3b53097cd4716e5db1447892cbbbe": "Publish Advisories\n\nGHSA-6qm6-v4xp-4rqj\nGHSA-7vvx-rvf8-xf4f\nGHSA-86h8-j4jv-gxpx"
39+
},
40+
"GHSA-86H8-J4JV-GXPX": {
41+
"f6d4e024d0b3b53097cd4716e5db1447892cbbbe": "Publish Advisories\n\nGHSA-6qm6-v4xp-4rqj\nGHSA-7vvx-rvf8-xf4f\nGHSA-86h8-j4jv-gxpx"
42+
},
43+
"GHSA-X6VC-HQP6-WXJ4": {
44+
"183e24fb6b1c7fe0f89e900af38fb39872126b95": "Publish GHSA-x6vc-hqp6-wxj4"
45+
},
446
"GHSA-CP6Q-959Q-F8RH": {
547
"f4f155e8b8ddc0d114c9e03baae2a835bf3f08ec": "Improve GHSA-cp6q-959q-f8rh",
648
"d4741382dc58cd8cf90cccdbf594362af08d7dc5": "Improve GHSA-cp6q-959q-f8rh",

data/fix-commits/bpf-next.git-239dca35.json

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,17 @@
11
{
22
"vcs_url": "https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git",
33
"vulnerabilities": {
4+
"CVE-2023-3439": {
5+
"408da1df18116c971c3392e21e50586688cd3fbf": "net: mctp: hold a reference to the route device in mctp_route_lookup()\n\nmctp_route_lookup() uses rt->dev without holding a reference on it.\nmctp_route_lookup_single() returns the route under RCU only, so the\nroute's device can be torn down concurrently: mctp_dev_put() drops the\nlast reference and synchronously kfree()s mdev->addrs. mctp_dev_saddr()\nthen reads rt->dev->addrs[0], giving a use-after-free reachable by an\nunprivileged local AF_MCTP user on the receive/forwarding path (no\nCAP_NET_RAW required):\n\n BUG: KASAN: slab-use-after-free in mctp_route_lookup\n Read of size 1 at addr ... by task mctp_uaf/...\n mctp_route_lookup\n mctp_pkttype_receive\n Freed by task ...:\n kfree\n mctp_dev_put\n mctp_dev_notify\n\nIn the same window mctp_dst_from_route() -> mctp_dev_hold() also\nincrements a refcount that has already reached zero\n(\"refcount_t: addition on 0 ... mctp_dev_hold\").\n\nThis reintroduces the use-after-free class of CVE-2023-3439: the source\naddress lookup was moved ahead of the point where the destination takes\nits device reference.\n\nTake a reference with refcount_inc_not_zero() before touching rt->dev,\nskip a device that is already dead, and drop the reference once the\ndestination has taken its own.\n\nFixes: 22cb45afd221 (\"net: mctp: perform source address lookups when we populate our dst\")\nCc: stable@vger.kernel.org\nSigned-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>\nLink: https://patch.msgid.link/20260813022102.2792032-1-qwe.aldo@gmail.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>"
6+
},
47
"CVE-2026-68445": {
58
"a5edadbae57e2298a56cf7a4e774a027905a331f": "ptp: vmclock: prevent read-only mappings from becoming writable\n\nvmclock_miscdev_mmap() rejects writable mappings of the shared vmclock\nABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the\npage read-only and then upgrade it to writable with mprotect(), after\nwhich the guest can corrupt the host-written timekeeping data (sequence\ncounter, UTC time, TSC offset) that the vmclock ABI defines as read-only.\n\nClear VM_MAYWRITE on the read-only path so the mapping cannot be\nupgraded, as i915 does for its read-only objects and as fixed in drm/vc4\n(CVE-2026-68445) and drm/panthor (CVE-2024-53071).\n\nCc: stable@vger.kernel.org\nFixes: 205032724226 (\"ptp: Add support for the AMZNC10C 'vmclock' device\")\nSigned-off-by: Abdifatah Suruur <suruurism@gmail.com>\nLink: https://patch.msgid.link/20260813174707.14809-1-suruurism@gmail.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>"
69
},
710
"CVE-2024-53071": {
811
"a5edadbae57e2298a56cf7a4e774a027905a331f": "ptp: vmclock: prevent read-only mappings from becoming writable\n\nvmclock_miscdev_mmap() rejects writable mappings of the shared vmclock\nABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the\npage read-only and then upgrade it to writable with mprotect(), after\nwhich the guest can corrupt the host-written timekeeping data (sequence\ncounter, UTC time, TSC offset) that the vmclock ABI defines as read-only.\n\nClear VM_MAYWRITE on the read-only path so the mapping cannot be\nupgraded, as i915 does for its read-only objects and as fixed in drm/vc4\n(CVE-2026-68445) and drm/panthor (CVE-2024-53071).\n\nCc: stable@vger.kernel.org\nFixes: 205032724226 (\"ptp: Add support for the AMZNC10C 'vmclock' device\")\nSigned-off-by: Abdifatah Suruur <suruurism@gmail.com>\nLink: https://patch.msgid.link/20260813174707.14809-1-suruurism@gmail.com\nSigned-off-by: Jakub Kicinski <kuba@kernel.org>"
912
},
1013
"CVE-2017-5753": {
14+
"5273183b6362cad9584bdfb5dddb2df30e4f5477": "platform/x86/amd/hsmp: Add IOCTL_GET_TELEMETRY_DATA for metric table reads\n\nThe metric table needs to be delivered to userspace as a single\natomic snapshot, but the current sysfs metrics_bin path is a file\nread: userspace can read it in chunks and observe a torn snapshot\nif an SMU refresh happens between read() calls. The same path is\nalso bounded by PAGE_SIZE, so the ~13 KB table used by HSMP protocol\nversion 7 on Family 1Ah Model 50h-5Fh cannot be returned at all,\nregardless of how userspace reads it. Rather than extend sysfs to\nlift both restrictions, expose the metric table through the\nexisting HSMP character device using a new ioctl that always copies\nthe table in one shot.\n\nAdd struct hsmp_telemetry_data and HSMP_IOCTL_GET_TELEMETRY_DATA\nto the UAPI header. Under the surrounding #pragma pack(4), placing\nthe __u64 user pointer first gives a tight 16-byte layout that is\nidentical for 32- and 64-bit callers, and the trailing __u16\nreserved field is rejected with -EINVAL if non-zero so future\nkernels can repurpose it without breaking already-deployed\nuserspace. The command is encoded with _IOW because the kernel only\nreads the request struct; the snapshot travels through the user\npointer it carries.\n\nThe requested size may be anything from one byte up to the size\nfirmware reported for that socket's table. A short request returns\nthe leading bytes of the snapshot, so userspace built against an\nolder table layout keeps working on firmware that grew the table,\nmirroring the relaxed response_sz rule applied to HSMP messages\nearlier in this series. A request larger than the firmware table is\nrejected with -EINVAL rather than short-written, so a caller can\nnever mistake a partial copy for a full one.\n\nDispatch hsmp_ioctl() on the ioctl command: the existing message\nhandler is factored out as hsmp_ioctl_msg() for HSMP_IOCTL_CMD, and\nHSMP_IOCTL_GET_TELEMETRY_DATA goes to a new\nhsmp_ioctl_get_telemetry() helper.\n\n/dev/hsmp is a singleton character device that outlives an\nindividual socket unbind, so an ioctl issued on an already-open fd\ncan run concurrently with socket teardown. hsmp_sock_rwsem is the\ndriver's contract for that: the data plane takes it for read, and\nprobe and remove take it for write to drain the data plane before\nfreeing the socket array, unmapping the metric tables and\ndestroying the per-socket mutexes. hsmp_ioctl_get_telemetry() takes\nit for read across the socket lookup, the checks on that socket's\nmetric-table state and the table read itself, so none of that state\ncan be torn down underneath it. Without this the handler would\nsleep in its kvmalloc() holding no lock at all, and could resume\nwith a freed socket, locking a destroyed mutex and reading from an\nunmapped iomem region.\n\nThe lock is dropped before the copy_to_user(), because faulting in\nthe destination can block indefinitely on a userfaultfd-backed\nbuffer and would otherwise leave a socket unbind waiting for the\nwrite lock.\n\nSince hsmp_metric_tbl_read() reached the mailbox through\nhsmp_send_message(), which takes hsmp_sock_rwsem itself, calling it\nwith the lock already held would recursively take the read side and\ncan deadlock against a queued writer. Split out\nhsmp_metric_tbl_read_locked(), which asserts the lock and uses\nhsmp_send_message_locked(), and leave hsmp_metric_tbl_read() as a\nwrapper that takes the read lock for the sysfs callers. This also\nbrings the whole fill-and-copy under the rwsem for those callers,\nwhere the memcpy_fromio() previously ran outside it, and makes the\nlock order uniformly hsmp_sock_rwsem -> metric_read_lock ->\nhsmp_sem.\n\nThe user-controlled socket index in HSMP_IOCTL_GET_TELEMETRY_DATA is\nclamped with array_index_nospec() before indexing hsmp_pdev.sock[],\nmitigating Spectre v1 (CVE-2017-5753). Include linux/nospec.h, which\nthe file relied on getting transitively.\n\nCo-developed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>\nSigned-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>\nSigned-off-by: Muralidhara M K <muralidhara.mk@amd.com>\nLink: https://patch.msgid.link/20260727141542.3370108-5-muralidhara.mk@amd.com\nReviewed-by: Ilpo J\u00e4rvinen <ilpo.jarvinen@linux.intel.com>\nSigned-off-by: Ilpo J\u00e4rvinen <ilpo.jarvinen@linux.intel.com>",
1115
"d20457b46eca76b9bb716dd31af591cad21607b5": "platform/x86/amd/hsmp: Clamp ioctl/send_message indices (Spectre v1)\n\nAlthough validate_message() checks msg_id, a mispredicted branch can\nstill allow speculative indexing into hsmp_msg_desc_table[]. Clamp\nmsg.msg_id with array_index_nospec() at entry to hsmp_ioctl_msg() so\ndownstream dereferences (including via is_get_msg() and\nhsmp_send_message()) see a bounded index.\n\nSimilarly, hsmp_send_message() bounds-checks msg->sock_ind before\nindexing hsmp_pdev.sock[], but a mispredicted branch can still\nspeculatively use the raw index (Spectre v1, CVE-2017-5753). Apply\narray_index_nospec() after the check so every caller that reaches\nhsmp_pdev.sock[] through this helper sees a clamped socket\nindex\u2014including hsmp_ioctl_msg() and any other path that hands a\nuser-derived struct hsmp_message to hsmp_send_message().\n\nReviewed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>\nSigned-off-by: Muralidhara M K <muralidhara.mk@amd.com>\nLink: https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.com\nReviewed-by: Ilpo J\u00e4rvinen <ilpo.jarvinen@linux.intel.com>\nSigned-off-by: Ilpo J\u00e4rvinen <ilpo.jarvinen@linux.intel.com>",
1216
"3214d01f139b7544e870fc0b7fcce8da13c1cb51": "KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds\n\nThis adds a new ioctl, KVM_PPC_GET_CPU_CHAR, that gives userspace\ninformation about the underlying machine's level of vulnerability\nto the recently announced vulnerabilities CVE-2017-5715,\nCVE-2017-5753 and CVE-2017-5754, and whether the machine provides\ninstructions to assist software to work around the vulnerabilities.\n\nThe ioctl returns two u64 words describing characteristics of the\nCPU and required software behaviour respectively, plus two mask\nwords which indicate which bits have been filled in by the kernel,\nfor extensibility. The bit definitions are the same as for the\nnew H_GET_CPU_CHARACTERISTICS hypercall.\n\nThere is also a new capability, KVM_CAP_PPC_GET_CPU_CHAR, which\nindicates whether the new ioctl is available.\n\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>",
1317
"05992edc279237d5803d64578e0c72b604970a49": "Merge branch 'kvm-insert-lfence'\n\nTopic branch for CVE-2017-5753, avoiding conflicts in the next merge window.",

0 commit comments

Comments
 (0)