Skip to content

Commit d3b3c5b

Browse files
1 parent 3fad8e2 commit d3b3c5b

6 files changed

Lines changed: 114 additions & 14 deletions

File tree

advisories/unreviewed/2025/05/GHSA-crp4-4q2h-fprq/GHSA-crp4-4q2h-fprq.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-crp4-4q2h-fprq",
4-
"modified": "2025-11-03T21:33:41Z",
4+
"modified": "2025-11-06T00:30:25Z",
55
"published": "2025-05-01T15:31:39Z",
66
"aliases": [
77
"CVE-2025-23141"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm->srcu when userspace is getting MP state to handle a\nrather extreme edge case where \"accepting\" APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory. If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of ->check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n =============================\n WARNING: suspicious RCU usage\n 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by triple_fault_ev/1256:\n #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n stack backtrace:\n CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n <TASK>\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x144/0x190\n kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n kvm_check_nested_events+0x1b/0x30 [kvm]\n kvm_apic_accept_events+0x33/0x100 [kvm]\n kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n __x64_sys_ioctl+0x8b/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n </TASK>",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -45,7 +50,7 @@
4550
],
4651
"database_specific": {
4752
"cwe_ids": [],
48-
"severity": null,
53+
"severity": "MODERATE",
4954
"github_reviewed": false,
5055
"github_reviewed_at": null,
5156
"nvd_published_at": "2025-05-01T13:15:49Z"

advisories/unreviewed/2025/05/GHSA-gh2h-q6h9-qfrw/GHSA-gh2h-q6h9-qfrw.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-gh2h-q6h9-qfrw",
4-
"modified": "2025-11-03T18:31:16Z",
4+
"modified": "2025-11-06T00:30:26Z",
55
"published": "2025-05-01T15:31:40Z",
66
"aliases": [
77
"CVE-2025-23143"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.\n\nWhen I ran the repro [0] and waited a few seconds, I observed two\nLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]\n\nReproduction Steps:\n\n 1) Mount CIFS\n 2) Add an iptables rule to drop incoming FIN packets for CIFS\n 3) Unmount CIFS\n 4) Unload the CIFS module\n 5) Remove the iptables rule\n\nAt step 3), the CIFS module calls sock_release() for the underlying\nTCP socket, and it returns quickly. However, the socket remains in\nFIN_WAIT_1 because incoming FIN packets are dropped.\n\nAt this point, the module's refcnt is 0 while the socket is still\nalive, so the following rmmod command succeeds.\n\n # ss -tan\n State Recv-Q Send-Q Local Address:Port Peer Address:Port\n FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445\n\n # lsmod | grep cifs\n cifs 1159168 0\n\nThis highlights a discrepancy between the lifetime of the CIFS module\nand the underlying TCP socket. Even after CIFS calls sock_release()\nand it returns, the TCP socket does not die immediately in order to\nclose the connection gracefully.\n\nWhile this is generally fine, it causes an issue with LOCKDEP because\nCIFS assigns a different lock class to the TCP socket's sk->sk_lock\nusing sock_lock_init_class_and_name().\n\nOnce an incoming packet is processed for the socket or a timer fires,\nsk->sk_lock is acquired.\n\nThen, LOCKDEP checks the lock context in check_wait_context(), where\nhlock_class() is called to retrieve the lock class. However, since\nthe module has already been unloaded, hlock_class() logs a warning\nand returns NULL, triggering the null-ptr-deref.\n\nIf LOCKDEP is enabled, we must ensure that a module calling\nsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded\nwhile such a socket is still alive to prevent this issue.\n\nLet's hold the module reference in sock_lock_init_class_and_name()\nand release it when the socket is freed in sk_prot_free().\n\nNote that sock_lock_init() clears sk->sk_owner for svc_create_socket()\nthat calls sock_lock_init_class_and_name() for a listening socket,\nwhich clones a socket by sk_clone_lock() without GFP_ZERO.\n\n[0]:\nCIFS_SERVER=\"10.0.0.137\"\nCIFS_PATH=\"//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST\"\nDEV=\"enp0s3\"\nCRED=\"/root/WindowsCredential.txt\"\n\nMNT=$(mktemp -d /tmp/XXXXXX)\nmount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1\n\niptables -A INPUT -s ${CIFS_SERVER} -j DROP\n\nfor i in $(seq 10);\ndo\n umount ${MNT}\n rmmod cifs\n sleep 1\ndone\n\nrm -r ${MNT}\n\niptables -D INPUT -s ${CIFS_SERVER} -j DROP\n\n[1]:\nDEBUG_LOCKS_WARN_ON(1)\nWARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)\nModules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]\nCPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)\n...\nCall Trace:\n <IRQ>\n __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178)\n lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)\n _raw_spin_lock_nested (kernel/locking/spinlock.c:379)\n tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)\n...\n\nBUG: kernel NULL pointer dereference, address: 00000000000000c4\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36\nTainted: [W]=WARN\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__lock_acquire (kernel/\n---truncated---",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -56,8 +61,10 @@
5661
}
5762
],
5863
"database_specific": {
59-
"cwe_ids": [],
60-
"severity": null,
64+
"cwe_ids": [
65+
"CWE-476"
66+
],
67+
"severity": "MODERATE",
6168
"github_reviewed": false,
6269
"github_reviewed_at": null,
6370
"nvd_published_at": "2025-05-01T13:15:50Z"

advisories/unreviewed/2025/05/GHSA-q7q7-437c-qxh7/GHSA-q7q7-437c-qxh7.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-q7q7-437c-qxh7",
4-
"modified": "2025-11-03T21:33:41Z",
4+
"modified": "2025-11-06T00:30:26Z",
55
"published": "2025-05-01T15:31:39Z",
66
"aliases": [
77
"CVE-2025-23142"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere's a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \"dead\". In order to do this,\nthe patch restores the \"dead\" bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\"sctp: remove the dead field of sctp_transport\").\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -60,8 +65,10 @@
6065
}
6166
],
6267
"database_specific": {
63-
"cwe_ids": [],
64-
"severity": null,
68+
"cwe_ids": [
69+
"CWE-416"
70+
],
71+
"severity": "HIGH",
6572
"github_reviewed": false,
6673
"github_reviewed_at": null,
6774
"nvd_published_at": "2025-05-01T13:15:50Z"

advisories/unreviewed/2025/05/GHSA-vvgj-gr7g-xwww/GHSA-vvgj-gr7g-xwww.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-vvgj-gr7g-xwww",
4-
"modified": "2025-11-03T21:33:41Z",
4+
"modified": "2025-11-06T00:30:25Z",
55
"published": "2025-05-01T15:31:39Z",
66
"aliases": [
77
"CVE-2025-23140"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error\n\nAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),\nthe pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs\nhave been released.\n\nHowever, some requested IRQs remain unreleased, so there are still\n/proc/irq/* entries remaining, and this results in WARN() with the\nfollowing message:\n\n remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0'\n WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c\n\nTo solve this issue, set the number of remaining IRQs to test->num_irqs,\nand release IRQs in advance by calling pci_endpoint_test_release_irq().\n\n[kwilczynski: commit log]",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -57,7 +62,7 @@
5762
],
5863
"database_specific": {
5964
"cwe_ids": [],
60-
"severity": null,
65+
"severity": "MODERATE",
6166
"github_reviewed": false,
6267
"github_reviewed_at": null,
6368
"nvd_published_at": "2025-05-01T13:15:49Z"
Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-8gg4-hx7q-h82p",
4+
"modified": "2025-11-06T00:30:26Z",
5+
"published": "2025-11-06T00:30:26Z",
6+
"aliases": [
7+
"CVE-2025-55278"
8+
],
9+
"details": "Improper authentication in the API authentication middleware of HCL DevOps Loop allows authentication tokens to be accepted without proper validation of their expiration and cryptographic signature. As a result, an attacker could potentially use expired or tampered tokens to gain unauthorized access to sensitive resources and perform actions with elevated privileges.",
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N"
14+
}
15+
],
16+
"affected": [],
17+
"references": [
18+
{
19+
"type": "ADVISORY",
20+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55278"
21+
},
22+
{
23+
"type": "WEB",
24+
"url": "https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0124203"
25+
}
26+
],
27+
"database_specific": {
28+
"cwe_ids": [
29+
"CWE-347"
30+
],
31+
"severity": "HIGH",
32+
"github_reviewed": false,
33+
"github_reviewed_at": null,
34+
"nvd_published_at": "2025-11-05T23:16:05Z"
35+
}
36+
}
Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-mcg2-rcmm-mhww",
4+
"modified": "2025-11-06T00:30:26Z",
5+
"published": "2025-11-06T00:30:26Z",
6+
"aliases": [
7+
"CVE-2025-12779"
8+
],
9+
"details": "Improper handling of the authentication token in the Amazon WorkSpaces client for Linux, versions 2023.0 through 2024.8, may expose the authentication token for DCV-based WorkSpaces to other local users on the same client machine. Under certain circumstances, a local user may be able to extract another local user's authentication token from the shared client machine and access their WorkSpace.\n\nTo mitigate this issue, users should upgrade to the Amazon WorkSpaces client for Linux version 2025.0 or later.",
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
14+
},
15+
{
16+
"type": "CVSS_V4",
17+
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
18+
}
19+
],
20+
"affected": [],
21+
"references": [
22+
{
23+
"type": "ADVISORY",
24+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12779"
25+
},
26+
{
27+
"type": "WEB",
28+
"url": "https://aws.amazon.com/security/security-bulletins/AWS-2025-025"
29+
}
30+
],
31+
"database_specific": {
32+
"cwe_ids": [
33+
"CWE-497"
34+
],
35+
"severity": "HIGH",
36+
"github_reviewed": false,
37+
"github_reviewed_at": null,
38+
"nvd_published_at": "2025-11-05T22:15:33Z"
39+
}
40+
}

0 commit comments

Comments
 (0)