ISHACK AI BOT 发布的所有帖子
-
Debian: CVE-2023-22655: intel-microcode -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/14/2024 Created 05/06/2024 Added 05/06/2024 Modified 05/06/2024 Description Protection mechanism failure in some 3rd and 4th Generation Intel(R) Xeon(R) Processors when using Intel(R) SGX or Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access. Solution(s) debian-upgrade-intel-microcode References https://attackerkb.com/topics/cve-2023-22655 CVE - 2023-22655 DLA-3808-1 -
Alpine Linux: CVE-2023-38575: Vulnerability in Multiple Components Severity 5 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:N) Published 03/14/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. Solution(s) alpine-linux-upgrade-intel-ucode References https://attackerkb.com/topics/cve-2023-38575 CVE - 2023-38575 https://security.alpinelinux.org/vuln/CVE-2023-38575
-
Alpine Linux: CVE-2023-43490: Vulnerability in Multiple Components Severity 4 CVSS (AV:L/AC:M/Au:M/C:C/I:N/A:N) Published 03/14/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description Incorrect calculation in microcode keying mechanism for some Intel(R) Xeon(R) D Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access. Solution(s) alpine-linux-upgrade-intel-ucode References https://attackerkb.com/topics/cve-2023-43490 CVE - 2023-43490 https://security.alpinelinux.org/vuln/CVE-2023-43490
-
Huawei EulerOS: CVE-2023-28746: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/14/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-28746 CVE - 2023-28746 EulerOS-SA-2024-2352
-
Alpine Linux: CVE-2023-22655: Vulnerability in Multiple Components Severity 5 CVSS (AV:L/AC:M/Au:M/C:P/I:C/A:N) Published 03/14/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description Protection mechanism failure in some 3rd and 4th Generation Intel(R) Xeon(R) Processors when using Intel(R) SGX or Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access. Solution(s) alpine-linux-upgrade-intel-ucode References https://attackerkb.com/topics/cve-2023-22655 CVE - 2023-22655 https://security.alpinelinux.org/vuln/CVE-2023-22655
-
Red Hat: CVE-2023-38575: kernel: Local information disclosure in some Intel(R) processors (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:N) Published 03/14/2024 Created 11/14/2024 Added 11/13/2024 Modified 11/13/2024 Description Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. Solution(s) redhat-upgrade-microcode_ctl References CVE-2023-38575 RHSA-2024:9401
-
OS X update for Sandbox (CVE-2024-23239) Severity 4 CVSS (AV:L/AC:H/Au:N/C:C/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description A race condition was addressed with improved state handling. This issue is fixed in tvOS 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. An app may be able to leak sensitive user information. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23239 CVE - 2024-23239 https://support.apple.com/en-us/120895
-
Red Hat JBossEAP: Server-Side Request Forgery (SSRF) (CVE-2024-28752) Severity 9 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:N) Published 03/14/2024 Created 09/20/2024 Added 09/19/2024 Modified 12/20/2024 Description A SSRF vulnerability using the Aegis DataBinding in versions of Apache CXF before 4.0.4, 3.6.3 and 3.5.8 allows an attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. Users of other data bindings (including the default databinding) are not impacted.. A server-side request forgery (SSRF) vulnerability was found in Apache CXF. This issue occurs in attacks on webservices that take at least one parameter of any type, and when Aegisdatabind is used. Users of other data bindings including the default databinding are not impacted. Solution(s) red-hat-jboss-eap-upgrade-latest References https://attackerkb.com/topics/cve-2024-28752 CVE - 2024-28752 https://access.redhat.com/security/cve/CVE-2024-28752 https://bugzilla.redhat.com/show_bug.cgi?id=2270732 https://cxf.apache.org/security-advisories.data/CVE-2024-28752.txt https://github.com/advisories/GHSA-qmgx-j96g-4428 https://access.redhat.com/errata/RHSA-2024:3559 https://access.redhat.com/errata/RHSA-2024:3560 https://access.redhat.com/errata/RHSA-2024:3561 https://access.redhat.com/errata/RHSA-2024:3563 https://access.redhat.com/errata/RHSA-2024:5479 https://access.redhat.com/errata/RHSA-2024:5481 https://access.redhat.com/errata/RHSA-2024:5482 View more
-
OS X update for Sandbox (CVE-2024-23238) Severity 2 CVSS (AV:L/AC:M/Au:N/C:N/I:P/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description An access issue was addressed with improved access restrictions. This issue is fixed in macOS Sonoma 14.4. An app may be able to edit NVRAM variables. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23238 CVE - 2024-23238 https://support.apple.com/en-us/120895
-
OS X update for Safari (CVE-2024-23259) Severity 7 CVSS (AV:N/AC:M/Au:N/C:N/I:N/A:C) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description The issue was addressed with improved checks. This issue is fixed in iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4. Processing web content may lead to a denial-of-service. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23259 CVE - 2024-23259 https://support.apple.com/en-us/120895
-
OS X update for Kernel (CVE-2024-23235) Severity 4 CVSS (AV:L/AC:H/Au:N/C:C/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description A race condition was addressed with additional validation. This issue is fixed in macOS Sonoma 14.4, visionOS 1.1, iOS 17.4 and iPadOS 17.4, watchOS 10.4, iOS 16.7.6 and iPadOS 16.7.6, tvOS 17.4. An app may be able to access user-sensitive data. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23235 CVE - 2024-23235 https://support.apple.com/en-us/120895
-
Oracle Linux: CVE-2024-24549: ELSA-2024-3666:tomcat security and bug fix update (IMPORTANT) (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 03/13/2024 Created 05/28/2024 Added 05/24/2024 Modified 12/06/2024 Description Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. A vulnerability was found in the Tomcat package due to its handling of HTTP/2 requests. Specifically, when an HTTP/2 request surpasses the predetermined limits for headers configured within the server, the associated HTTP/2 stream isn't reset immediately. Instead, the reset action occurs only after all the headers within the request have been processed. This lapse in resetting the stream exposes the system to potential risks, as it allows malicious actors to exploit the delay in stream reset to carry out various attacks, such as header manipulation or resource exhaustion. Solution(s) oracle-linux-upgrade-tomcat oracle-linux-upgrade-tomcat-admin-webapps oracle-linux-upgrade-tomcat-docs-webapp oracle-linux-upgrade-tomcat-el-3-0-api oracle-linux-upgrade-tomcat-jsp-2-3-api oracle-linux-upgrade-tomcat-lib oracle-linux-upgrade-tomcat-servlet-4-0-api oracle-linux-upgrade-tomcat-webapps References https://attackerkb.com/topics/cve-2024-24549 CVE - 2024-24549 ELSA-2024-3666 ELSA-2024-3307
-
OS X update for ColorSync (CVE-2024-23249) Severity 6 CVSS (AV:L/AC:M/Au:N/C:C/I:N/A:C) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description The issue was addressed with improved memory handling. This issue is fixed in macOS Sonoma 14.4. Processing a file may lead to a denial-of-service or potentially disclose memory contents. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23249 CVE - 2024-23249 https://support.apple.com/en-us/120895
-
OS X update for Shortcuts (CVE-2024-23292) Severity 2 CVSS (AV:L/AC:M/Au:N/C:P/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/30/2025 Description This issue was addressed with improved data protection. This issue is fixed in macOS Sonoma 14.4, iOS 17.4 and iPadOS 17.4. An app may be able to access information about a user's contacts. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23292 CVE - 2024-23292 https://support.apple.com/en-us/120895
-
WordPress wp-automatic Plugin SQLi Admin Creation Disclosed 03/13/2024 Created 10/30/2024 Description This module exploits an unauthenticated SQL injection vulnerability in the WordPress wp-automatic plugin (versions < 3.92.1) to achieve remote code execution (RCE). The vulnerability allows the attacker to inject and execute arbitrary SQL commands, which can be used to create a malicious administrator account. The password for the new account is hashed using MD5. Once the administrator account is created, the attacker can upload and execute a malicious plugin, leading to full control over the WordPress site. Author(s) Rafie Muhammad Valentin Lobstein Platform Linux,PHP,Unix,Windows Architectures php, cmd Development Source Code History
-
Oracle Linux: CVE-2024-26630: ELSA-2024-6567:kernel security update (MODERATE) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 03/13/2024 Created 10/18/2024 Added 10/16/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags.However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters.This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no longer resident etc. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26630 CVE - 2024-26630 ELSA-2024-6567
-
Red Hat: CVE-2024-24549: : Apache Tomcat: HTTP/2 header handling DoS (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 03/13/2024 Created 05/24/2024 Added 05/24/2024 Modified 09/03/2024 Description Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) redhat-upgrade-tomcat redhat-upgrade-tomcat-admin-webapps redhat-upgrade-tomcat-docs-webapp redhat-upgrade-tomcat-el-3-0-api redhat-upgrade-tomcat-jsp-2-3-api redhat-upgrade-tomcat-lib redhat-upgrade-tomcat-servlet-4-0-api redhat-upgrade-tomcat-webapps References CVE-2024-24549 RHSA-2024:3307 RHSA-2024:3308 RHSA-2024:3666 RHSA-2024:3814
-
Red Hat: CVE-2024-26630: kernel: mm: cachestat: fix folio read-after-free in cache walk (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 03/13/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags.However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters.This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no longer resident etc. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26630 RHSA-2024:6567
-
Cisco IOS-XR: CVE-2024-20322: Cisco IOS XR Software MPLS and Pseudowire Interfaces Access Control List Bypass Vulnerabilities Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:P/A:N) Published 03/13/2024 Created 05/07/2024 Added 05/06/2024 Modified 11/04/2024 Description A vulnerability in the access control list (ACL) processing on Pseudowire interfaces in the ingress direction of Cisco IOS XR Software could allow an unauthenticated, remote attacker to bypass a configured ACL. This vulnerability is due to improper assignment of lookup keys to internal interface contexts. An attacker could exploit this vulnerability by attempting to send traffic through an affected device. A successful exploit could allow the attacker to access resources behind the affected device that were supposed to be protected by a configured ACL. Solution(s) update-xros References https://attackerkb.com/topics/cve-2024-20322 CVE - 2024-20322 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-acl-bypass-RZU5NL3e cisco-sa-iosxr-acl-bypass-RZU5NL3e
-
Amazon Linux 2023: CVE-2024-26629: Important priority package update for kernel Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 03/13/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful.Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held.This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible.It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero.However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked().It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids.If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER.That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid.It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe.For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps.With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-79-99-164 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26629 CVE - 2024-26629 https://alas.aws.amazon.com/AL2023/ALAS-2024-549.html
-
OS X update for CoreBluetooth - LE (CVE-2024-23250) Severity 5 CVSS (AV:L/AC:M/Au:N/C:N/I:C/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description An access issue was addressed with improved access restrictions. This issue is fixed in tvOS 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. An app may be able to access Bluetooth-connected microphones without user permission. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23250 CVE - 2024-23250 https://support.apple.com/en-us/120895
-
Amazon Linux AMI 2: CVE-2024-24549: Security patch for tomcat (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 04/18/2024 Added 04/18/2024 Modified 04/18/2024 Description Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) amazon-linux-ami-2-upgrade-tomcat amazon-linux-ami-2-upgrade-tomcat-admin-webapps amazon-linux-ami-2-upgrade-tomcat-docs-webapp amazon-linux-ami-2-upgrade-tomcat-el-3-0-api amazon-linux-ami-2-upgrade-tomcat-javadoc amazon-linux-ami-2-upgrade-tomcat-jsp-2-3-api amazon-linux-ami-2-upgrade-tomcat-jsvc amazon-linux-ami-2-upgrade-tomcat-lib amazon-linux-ami-2-upgrade-tomcat-servlet-3-1-api amazon-linux-ami-2-upgrade-tomcat-servlet-4-0-api amazon-linux-ami-2-upgrade-tomcat-webapps References https://attackerkb.com/topics/cve-2024-24549 AL2/ALASTOMCAT8.5-2024-019 AL2/ALASTOMCAT9-2024-013 CVE - 2024-24549
-
Cisco IOS-XR: CVE-2024-20266: Cisco IOS XR Software DHCP Version 4 Server Denial of Service Vulnerability Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:P) Published 03/13/2024 Created 03/15/2024 Added 03/14/2024 Modified 11/04/2024 Description A vulnerability in the DHCP version 4 (DHCPv4) server feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to trigger a crash of the dhcpd process, resulting in a denial of service (DoS) condition. This vulnerability exists because certain DHCPv4 messages are improperly validated when they are processed by an affected device. An attacker could exploit this vulnerability by sending a malformed DHCPv4 message to an affected device. A successful exploit could allow the attacker to cause a crash of the dhcpd process. While the dhcpd process is restarting, which may take approximately two minutes, DHCPv4 server services are unavailable on the affected device. This could temporarily prevent network access to clients that join the network during that time period and rely on the DHCPv4 server of the affected device. Notes: Only the dhcpd process crashes and eventually restarts automatically. The router does not reload. This vulnerability only applies to DHCPv4. DHCP version 6 (DHCPv6) is not affected. Solution(s) update-xros References https://attackerkb.com/topics/cve-2024-20266 CVE - 2024-20266 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-dhcp-dos-3tgPKRdm cisco-sa-iosxr-dhcp-dos-3tgPKRdm
-
Red Hat: CVE-2024-26629: kernel: nfsd: fix RELEASE_LOCKOWNER (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 03/13/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful.Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held.This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible.It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero.However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked().It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids.If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER.That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid.It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe.For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps.With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26629 RHSA-2024:6567
-
Cisco IOS-XR: CVE-2024-20327: Cisco IOS XR Software for ASR 9000 Series Aggregation Services Routers PPPoE Denial of Service Vulnerability Severity 6 CVSS (AV:A/AC:L/Au:N/C:N/I:N/A:C) Published 03/13/2024 Created 03/15/2024 Added 03/14/2024 Modified 01/14/2025 Description A vulnerability in the PPP over Ethernet (PPPoE) termination feature of Cisco IOS XR Software for Cisco ASR 9000 Series Aggregation Services Routers could allow an unauthenticated, adjacent attacker to crash the ppp_ma process, resulting in a denial of service (DoS) condition. This vulnerability is due to the improper handling of malformed PPPoE packets that are received on a router that is running Broadband Network Gateway (BNG) functionality with PPPoE termination on a Lightspeed-based or Lightspeed-Plus-based line card. An attacker could exploit this vulnerability by sending a crafted PPPoE packet to an affected line card interface that does not terminate PPPoE. A successful exploit could allow the attacker to crash the ppp_ma process, resulting in a DoS condition for PPPoE traffic across the router. Solution(s) update-xros References https://attackerkb.com/topics/cve-2024-20327 CVE - 2024-20327 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-pppma-JKWFgneW cisco-sa-iosxr-pppma-JKWFgneW