CVE-2024-47535

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Summary

An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash.

Details

When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed.

At this stage, Netty tries to load both /etc/os-release and /usr/lib/os-release even though it is in a Windows environment.

<img width="364" alt="1" src="https://github.com/user-attachments/assets/9466b181-9394-45a3-b0e3-1dcf105def59">

If netty finds this files, it reads them and loads them into memory.

By default :

• The JVM maximum memory size is set to 1 GB,
• A non-privileged user can create a directory at C:\ and create files within it.

<img width="340" alt="2" src="https://github.com/user-attachments/assets/43b359a2-5871-4592-ae2b-ffc40ac76831">

<img width="523" alt="3" src="https://github.com/user-attachments/assets/ad5c6eed-451c-4513-92d5-ba0eee7715c1">

the source code identified : https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java

Despite the implementation of the function normalizeOs() the source code not verify the OS before reading C:\etc\os-release and C:\usr\lib\os-release.

PoC

Create a file larger than 1 GB of data in C:\etc\os-release or C:\usr\lib\os-release on a Windows environnement and start your Netty application.

To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/)

cd C:\etc
fsutil file createnew os-release 3000000000

<img width="519" alt="4" src="https://github.com/user-attachments/assets/39df22a3-462b-4fd0-af9a-aa30077ec08f">

<img width="517" alt="5" src="https://github.com/user-attachments/assets/129dbd50-fc36-4da5-8eb1-582123fb528f">

The source code used is the Netty website code example : Echo ‐ the very basic client and server.

The vulnerability was tested on the 4.1.112.Final version.

The security analyst tried the same technique for C:\proc\sys\net\core\somaxconn with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186

Impact

By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application.

This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists.

Client mode :

<img width="449" alt="6" src="https://github.com/user-attachments/assets/f8fe1ed0-1a42-4490-b9ed-dbc9af7804be">

Server mode :

<img width="464" alt="7" src="https://github.com/user-attachments/assets/b34b42bd-4fbd-4170-b93a-d29ba87b88eb">

somaxconn :

<img width="532" alt="8" src="https://github.com/user-attachments/assets/0656b3bb-32c6-4ae2-bff7-d93babba08a3">

Severity

• Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running.
• Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents).
• Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability.
• User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings.
• Scope : "Unchanged" because only Netty is affected by the vulnerability.
• Confidentiality : "None" because no data is exposed through exploiting the vulnerability.
• Integrity : "None" because the…

Red Hat Lightwell has released io.netty:netty-common 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2024-47535 and CVE-2025-25193.

CVE-2024-47535: Denial of Service attack on windows app using Netty

CVE-2025-25193: Denial of Service attack on windows app using Netty

This patched artifact is a drop-in replacement for io.netty:netty-common 4.1.100.Final from Maven Central.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crashes. This vulnerability is fixed in 4.1.115.

TuxCare rebuilt 43 io.netty packages to address 12 CVEs. Fixed in 4.1.63.Final-tuxcare.2.

TuxCare rebuilt 40 io.netty packages to address 16 CVEs. Fixed in 4.1.52.Final-tuxcare.1.

TuxCare rebuilt 43 io.netty packages to address 15 CVEs. Fixed in 4.1.60.Final-tuxcare.1.

TuxCare rebuilt 46 io.netty packages to address 9 CVEs. Fixed in 4.1.75.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 12 CVEs. Fixed in 4.1.93.Final-tuxcare.1.

TuxCare rebuilt 46 io.netty packages to address 6 CVEs. Fixed in 4.1.73.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 7 CVEs. Fixed in 4.1.92.Final-tuxcare.1.

TuxCare rebuilt 42 io.netty packages to address 2 CVEs. Fixed in 4.1.58.Final-tuxcare.2.

TuxCare rebuilt 9 io.netty packages to address 14 CVEs. Fixed in 4.1.112.Final-tuxcare.5.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

TuxCare rebuilt 11 io.netty packages to address 18 CVEs. Fixed in 4.1.87.Final-tuxcare.1.

TuxCare rebuilt 4 io.netty packages to address 4 CVEs. Fixed in 4.1.107.Final-tuxcare.2.

TuxCare rebuilt 6 io.netty packages to address 7 CVEs. Fixed in 4.1.82.Final-tuxcare.8.

TuxCare rebuilt 46 io.netty packages to address 19 CVEs. Fixed in 4.1.80.Final-tuxcare.1.

TuxCare rebuilt 9 io.netty packages to address 13 CVEs. Fixed in 4.1.81.Final-tuxcare.1.

TuxCare rebuilt 15 io.netty packages to address 27 CVEs. Fixed in 4.1.72.Final-tuxcare.1.

TuxCare rebuilt 40 io.netty packages to address 26 CVEs. Fixed in 4.1.53.Final-tuxcare.1.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.43.Final-tuxcare.3.

TuxCare rebuilt 5 io.netty packages to address 6 CVEs. Fixed in 4.1.48.Final-tuxcare.5.

TuxCare rebuilt 10 io.netty packages to address 17 CVEs. Fixed in 4.1.49.Final-tuxcare.6.

TuxCare rebuilt 7 io.netty packages to address 13 CVEs. Fixed in 4.1.51.Final-tuxcare.2.

TuxCare rebuilt 5 io.netty packages to address 11 CVEs. Fixed in 4.1.42.Final-tuxcare.4.

TuxCare rebuilt 8 io.netty packages to address 16 CVEs. Fixed in 4.1.39.Final-tuxcare.2.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.114.Final-tuxcare.3.

TuxCare rebuilt 3 io.netty packages to address 6 CVEs. Fixed in 4.1.113.Final-tuxcare.3.

TuxCare rebuilt 8 io.netty packages to address 10 CVEs. Fixed in 4.1.74.Final-tuxcare.2.

These are all security issues fixed in the netty-4.1.115-1.1 package on the GA media of openSUSE Tumbleweed.

This update for aalto-xml, flatten-maven-plugin, jctools, moditect, netty, netty-tcnative fixes the following issues:

• CVE-2024-47535: Fixed unsafe reading of large environment files when Netty is loaded by a java application can lead to a crash due to the JVM memory limit being exceeded in netty (bsc#1233297)

Other fixes:

• Upgraded netty to upstream version 4.1.115
• Upgraded netty-tcnative to version 2.0.69 Final
• Updated jctools to version 4.0.5
• Updated aalto-xml to version 1.3.3
• Updated moditect to version 1.2.2
• Updated flatten-maven-plugin to version 1.6.0

This update fixes the following issues:

release-notes-susemanager:

• Update to SUSE Manager 4.3.15.2
  • SUSE Manager 4.3 will transition to LTS after June 2025
  • CVE Fixed CVE-2023-45288, CVE-2024-11741, CVE-2024-45337, CVE-2024-45339 CVE-2024-51744, CVE-2024-9264, CVE-2024-9476, CVE-2025-22870 CVE-2025-22872, CVE-2025-2703 CVE-2025-27144, CVE-2025-3454 CVE-2025-3580, CVE-2025-4123, CVE-2024-47535

This update fixes the following issues:

netty:

• Security issues fixed:

  • CVE-2024-47535: Decorate InputStream to throw an exception once the data read limit is reached (bsc#1233297)

• Other changes:

  • Replace AlgorithmId.sha256WithRSAEncryption_oid usage with specify the OID directly

susemanager-sync-data:

• Version 4.3.22-0:

  • Added support for OES 24.4 (bsc#1230585)
  • Set Ubuntu 24.04 as released

How to apply this update:

1. Log in as root user to the Multi-Linux Manager Server.
2. Stop the Spacewalk service: spacewalk-service stop
3. Apply the patch using either zypper patch or YaST Online Update.
4. Start the Spacewalk service: spacewalk-service start