Where
AND
-Infinity
0
Severity
5.5
EPSS
0.04%
Race Condition
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

sched/membarrier: reduce the ability to hammer on sysmembarrier

On some systems, sysmembarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.

1 / 7
Source: NVD
First published (updated )
Severity
6.5
Null Pointer Dereference
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.

1 / 2
First published (updated )
Severity
6.3
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Accounts. The issue was addressed with improved checks.

1 / 10
Source: Apple
First published (updated )
Severity
7.4
Input Validation
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Accounts. The issue was addressed with improved checks.

1 / 10
Source: Apple
First published (updated )
Severity
7.8
Use After Free, Double Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.

The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

1 / 7
Source: MITRE
First published (updated )
Severity
9.8
EPSS
0.10%
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

Dear Linux Developers,

We're reaching out to you as part of the disclosure process of our research.

In our research, which we will present at IEEE Security & Privacy in May 2024, we found that attackers can not only create TCP-spoofed connections (which was already known), but can also reliably transmit IP-spoofed data over such connections. This has security implications for applications that rely on TCP endpoint IP addresses, such as firewalling or host-based authentication (e.g., SMTP/SPF, of DBs).

We basically discovered two TCP spoofing primitives. First, attackers can bruteforce the server-chosen send window by acknowledging data that was never sent (what we call "ghost ACKs"; see Figure 3 in the paper). Second, we show that there are side channels that allow the attacker to leak the otherwise-secret server-chosen initial sequence number (ISN). One of these side channels leverages TCP SYN cookies.

We believe that the TCP/IP stack can take countermeasures to prevent such attacks, or at least make them harder. For example, we think that TCP endpoints should ignore ghost ACKs, and have some ideas to randomize the TCP backlog queue to prevent the SYN cookie side channel.

At the same time, we have disclosed our findings to the IETF folks and hope that they have helpful feedback for us.

1 / 4
Source: Red Hat
First published (updated )
Severity
5.3
EPSS
0.13%
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Excessive time spent in DH check / generation with large Q parameter value

1 / 6
Source: Microsoft
First published (updated )
Severity
6.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow.

Impact summary: Applications that use OBJobj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.

1 / 6
Source: Red Hat
First published (updated )
Severity
6.5
Command Injection, OS Command Injection, Race Condition, Buffer Overflow, Input Validation
AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

1 / 41
Source: Apple
First published (updated )
Severity
6.5
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

Last updated 31 October 2024

1 / 5
Source: Ubuntu
First published (updated )
Severity
7.5
EPSS
0.18%
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

1 / 6
Source: NVD
First published (updated )
Severity
6.7
AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

An out-of-bounds memory write flaw in the Linux kernel’s USB Monitor component was found in how a user with access to the /dev/usbmon can trigger it by an incorrect write to the memory of the usbmon. This flaw allows a local user to crash or potentially escalate their privileges on the system.

1 / 4
First published (updated )
Severity
7.8
Use After Free, Double Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A use-after-free flaw was found in route4change in the net/sched/clsroute.c filter implementation in the Linux kernel. This flaw allows a local user to crash the system and possibly lead to a local privilege escalation problem.

1 / 5
First published (updated )
Severity
5.3
Infoleak
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

A fundamental design flaw within the RADIUS protocol has been proven to be exploitable, compromising the integrity in the RADIUS Access-Request process. The attack allows a malicious user to modify packets in a way that would be indistinguishable to a RADIUS client or server. To be successful, the attacker must have the ability to inject themselves between the client and server.

1 / 6
Source: FortiGuard

Remedy

Disable the use of RADIUS/UDP and RADIUS/TCP - instead RADIUS/TLS or RADIUS/DTLS should be used.

Remedy

TBD

Remedy

The best way to address this issue is by using encrypted and authenticated channels that offer modern cryptographic security guarantees. Configure an alternate authentication mechanism if you are using RADIUS with a CHAP or PAP authentication protocol. PAN-OS provides the following alternate RADIUS authentication mechanisms: PEAP-MSCHAPv2 (default), PEAP with GTC, and EAP-TTLS with PAP. For more information, please see https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/authentication/configure-radius-authentication. In addition, instead of using RADIUS, you can configure an alternate authentication mechanism using one of the options described here: https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/authentication. If you are a Prisma Access customer using a RADIUS configuration with PAP or CHAP in your profile and have not applied one of the changes described above, please reach out to TAC/CS to schedule an upgrade window. PAN-OS 9.1.19, PAN-OS 10.1.14, PAN-OS 10.2.10, PAN-OS 11.0.7, PAN-OS 11.1.3, and all later PAN-OS versions add a new feature to enforce an authentication check in RADIUS. This new feature is disabled by default to match the existing behavior. To enable this feature, run the following commands: > set auth radius-require-msg-authentic yes To confirm that the setting was correctly enabled, run the following command: > show auth radius-require-msg-authentic If set correctly, the response will say "yes". This setting is persistent across reboots. No ‘commit’ is required for this to take effect. Please note that this feature requires that the RADIUS server has been updated to support the new protocol changes, as detailed in https://kb.cert.org/vuls/id/456537. If your RADIUS authentication breaks when radius-require-msg-authentic is set to yes, please work with your RADIUS server vendor for support with the RADIUS server upgrade process.
First published (updated )
Severity
7.5
EPSS
0.04%
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 18 September 2024

1 / 3
Source: Ubuntu
First published (updated )
Severity
6.5
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Gather Date Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processor. In this flaw, a local attack using gather instruction (load from memory) may infer stale data from previously used vector registers on the same physical core.

1 / 4
Source: Red Hat
First published (updated )
Severity
5.9
Null Pointer Dereference
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.

First published (updated )
Severity
8.3
Race Condition
CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:N/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

Race condition in Seamless Firmware Updates for some Intel(R) reference platforms may allow a privileged user to potentially enable denial of service via local access.

First published (updated )
Severity
Race Condition
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

Race condition in Seamless Firmware Updates for some Intel(R) reference platforms may allow a privileged user to potentially enable denial of service via local access.

First published (updated )
Severity
4.1
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

CVE-2023-5981 A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding. CVE-2024-0553 A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

First published (updated )
Severity
5.9
EPSS
0.06%
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

1 / 5
Source: Ubuntu
First published (updated )
Severity
7.2
Input Validation
CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:N/VA:H/SC:H/SI:N/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

Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to enable information disclosure or denial of service via local access.

First published (updated )
Severity
Input Validation
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H

Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to enable information disclosure or denial of service via local access.

First published (updated )
Severity
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytesacked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCKSTREAM, IPPROTOTCP) = 3 +0 setsockopt(3, SOLSOCKET, SOREUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (ServerISN+1-1073725440. ServerISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001

First published (updated )
Severity
6.8
CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/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

Improper conditions check in some Intel(R) Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access.

First published (updated )
Severity
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

Improper conditions check in some Intel(R) Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access.

First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DHgeneratekey() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DHcheckpubkey(), DHcheckpubkeyex() or EVPPKEYpubliccheck() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. While DHcheck() performs all the necessary checks (as of CVE-2023-3817), DHcheckpubkey() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DHgeneratekey() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DHgeneratekey() or DHcheckpubkey() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DHgeneratekey() and DHcheckpubkey() are also called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DHcheckpubkeyex(), EVPPKEYpubliccheck(), and EVPPKEYgenerate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

First published (updated )
Severity
5.7
EPSS
0.04%
Buffer Overflow, XSS, SQL Injection, Input Validation, Code Injection, Race Condition
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.

First published (updated )
Severity
7.8
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
First published (updated )
Advisory
F5-K32615023
Severity
6.7
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

drivers/usb/mon/monbin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203