netrc and default credential leak

Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSLVERIFYPEER verification mode is set.

Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients.

RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSLVERIFYPEER.

Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSLgetverifyresult(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.

Last updated 10 July 2026

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes.

Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low.

In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding.

The affected APIs include: ECGROUPnewcurveGF2m(), ECGROUPnewfromparams(), and various supporting BNGF2m() functions.

Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Abnormal termination of an application can a cause a denial of service.

Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address when comparing the expected name with an otherName subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program.

Note that basic certificate chain validation (signatures, dates, ...) is not affected, the denial of service can occur only when the application also specifies an expected DNS name, Email address or IP address.

TLS servers rarely solicit client certificates, and even when they do, they generally don't perform a name check against a "reference identifier" (expected identity), but rather extract the presented identity after checking the certificate chain. So TLS servers are generally not affected and the severity of the issue is Moderate.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15

Issue summary: Calling the OpenSSL API function SSLselectnextproto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.

A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSLfreebuffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications.

The SSLfreebuffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSLfreebuffers will succeed even though a record has only been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSLfreebuffers will succeed even though the buffer is still in use.

While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 1.0.2 is also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only).

Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1).

This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai).

Excessive time spent checking DSA keys and parameters

glibc is vulnerable to a denial of service, caused by a memory allocation failure when the Name Service Cache Daemon's (nscd) netgroup cache uses the xmalloc or xrealloc functions. A local attacker could exploit this vulnerability to terminate the daemon.

After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header.

In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=31678

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

ipv6: sr: fix possible use-after-free and null-ptr-deref

The Linux kernel CVE team has assigned CVE-2024-26735 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040359-CVE-2024-26735-462f@gregkh/T

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

arp: Prevent overflow in arpreqget().

syzkaller reported an overflown write in arpreqget(). [0]

When ioctl(SIOCGARP) is issued, arpreqget() looks up an neighbour entry and copies neigh->ha to struct arpreq.arpha.sadata.

The arpha here is struct sockaddr, not struct sockaddrstorage, so the sadata buffer is just 14 bytes.

In the splat below, 2 bytes are overflown to the next int field, arpflags. We initialise the field just after the memcpy(), so it's not a problem.

However, when dev->addrlen is greater than 22 (e.g. MAXADDRLEN), arpnetmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arpioctl() before calling arpreqget().

To avoid the overflow, let's limit the max length of memcpy().

Note that commit b5f0de6df6dc ("net: dev: Convert sadata to flexible array in struct sockaddr") just silenced syzkaller.

[0]: memcpy: detected field-spanning write (size 16) of single field "r->arpha.sadata" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: arpioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inetioctl+0x314/0x3a0 net/ipv4/afinet.c:981 sockdoioctl+0xdf/0x260 net/socket.c:1204 sockioctl+0x3ef/0x650 net/socket.c:1321 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:870 [inline] sesysioctl fs/ioctl.c:856 [inline] x64sysioctl+0x18e/0x220 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x37/0x90 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000

Accounts. The issue was addressed with improved checks.

Accounts. The issue was addressed with improved checks.

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

ip6tunnel: fix NEXTHDRFRAGMENT handling in ip6tnlparsetlvenclim()

syzbot pointed out [1] that NEXTHDRFRAGMENT handling is broken.

Reading fragoff can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.

[1] BUG: KMSAN: uninit-value in ip6tnlparsetlvenclim+0x94f/0xbb0 ip6tnlparsetlvenclim+0x94f/0xbb0 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 dokmallocnode mm/slabcommon.c:1006 [inline] kmallocnodetrackcaller+0x118/0x3c0 mm/slabcommon.c:1027 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 pskbexpandhead+0x226/0x1a00 net/core/skbuff.c:2098 pskbpulltail+0x13b/0x2310 net/core/skbuff.c:2655 pskbmaypullreason include/linux/skbuff.h:2673 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] ip6tnlparsetlvenclim+0x901/0xbb0 net/ipv6/ip6tunnel.c:408 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendms ---truncated---

libexpat could allow a remote attacker to obtain sensitive information, caused by improper handling of XML external entity (XXE) declarations by the XMLExternalEntityParserCreate function. By using a specially crafted XML content, a remote attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

drm/amdgpu: Fix possible NULL dereference in amdgpurasqueryerrorstatushelper()

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmaprmt.c.

Applications that use the function EVPPKEYpubliccheck() to check RSA public keys may experience long delays. Where the key that is being checked has been obtained from an untrusted source this may lead to a Denial of Service. An application that calls EVPPKEYpubliccheck() and supplies an RSA key obtained from an untrusted source could be vulnerable to a Denial of Service attack.

The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. OpenSSL versions 3.0.0 to 3.0.12, 3.1.0 to 3.1.4 and 3.2.0 are vulnerable to this issue. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue.

References: https://www.openssl.org/news/secadv/20240115.txt https://www.openwall.com/lists/oss-security/2024/01/15/2

Upstream fix: https://github.com/openssl/openssl/commit/18c02492138d1eb8b6548cb26e7b625fb2414a2a (3.0.13) https://github.com/openssl/openssl/commit/a830f551557d3d66a84bbb18a5b889c640c36294 (3.1.5) https://github.com/openssl/openssl/commit/0b0f7abfb37350794a4b8960fafc292cd5d1b84d (3.2.1)

An issue was discovered in the Linux kernel through 5.18.14. xfrmexpandpolicies in net/xfrm/xfrmpolicy.c can cause a refcount to be dropped twice.

A flaw was found in OpenSSL. The issue in CVE-2022-1292 did not find other places in the crehash script where it possibly passed the file names of certificates being hashed to a command executed through the shell. Some operating systems distribute this script in a manner where it is automatically executed. On these operating systems, this flaw allows an attacker to execute arbitrary commands with the privileges of the script.

An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watchqueue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.

A TCP/IP packet spoofing attack flaw was found in the Linux kernel’s TCP/IP protocol, where a Man-in-the-Middle Attack (MITM) performs an IP fragmentation attack and an IPID collision. This flaw allows a remote user to pretend to be the sender of the TCP/IP packet for an existing TCP/IP session.

A race condition was discovered in ext4writeinlinedataend in fs/ext4/inline.c in the ext4 subsystem in the Linux kernel through 5.13.13.

A flaw was found in the Linux SCTP stack. A blind attacker may be able to kill an existing SCTP association through invalid chunks if the attacker knows the IP-addresses and port numbers being used and the attacker can send packets with spoofed IP addresses.

A flaw was discovered in processing setsockopt IPTSOSETREPLACE (or IP6TSOSETREPLACE) for 32 bit processes on 64 bit systems. This flaw will allow local user to gain privileges or cause a DoS through user name space. This action is usually restricted to root-privileged users but can also be leveraged if the kernel is compiled with CONFIGUSERNS and CONFIGNETNS and the user is granted elevated privileges.

SELinux Project SELinux is vulnerable to a denial of service, caused by a use-after-free in cilresetclasspermission . By sending a specially-crafted request, a local attacker could exploit this vulnerability to cause a denial of service condition.