webkitgtk-2.48.1

[Bruce Dubbs]

New point version.

[Rahul Chandra]

Can confirm that the build works without the patch.

[Rahul Chandra]

What’s new in the WebKitGTK 2.48.1 release?

Limit the data stored in session state. Remove the empty area below the title bar in Web Inspector when not docked. Fix the build with GST_DISABLE_GST_DEBUG. Fix the build with GStreamer < 1.20. Fix the build with video disabled. Fix the build with clang 20.

[Douglas R. Reno]

------------------------------------------------------------------------
WebKitGTK and WPE WebKit Security Advisory                 WSA-2025-0003
------------------------------------------------------------------------

Date reported           : April 07, 2025
Advisory ID             : WSA-2025-0003
WebKitGTK Advisory URL  : https://webkitgtk.org/security/WSA-2025-0003.html
WPE WebKit Advisory URL : https://wpewebkit.org/security/WSA-2025-0003.html
CVE identifiers         : CVE-2024-54551, CVE-2025-24208,
                          CVE-2025-24209, CVE-2025-24213,
                          CVE-2025-24216, CVE-2025-24264,
                          CVE-2025-30427.

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

CVE-2024-54551
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to ajajfxhj.
    Impact: Processing web content may lead to a denial-of-service.
    Description: The issue was addressed with improved memory handling.
    WebKit Bugzilla: 275117

CVE-2025-24208
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to Muhammad Zaid Ghifari (Mr.ZheeV) and Kalimantan Utara.
    Impact: Loading a malicious iframe may lead to a cross-site
    scripting attack. Description: A permissions issue was addressed
    with additional restrictions.
    WebKit Bugzilla: 286381

CVE-2025-24209
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to Francisco Alonso (@revskills), and an anonymous researcher.
    Impact: Processing maliciously crafted web content may lead to an
    unexpected process crash. Description: A buffer overflow issue was
    addressed with improved memory handling.
    WebKit Bugzilla: 286462

CVE-2025-24213
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to Google V8 Security Team.
    Impact: A type confusion issue could lead to memory corruption.
    Description: This issue was addressed with improved handling of
    floats. Note that this CVE is fixed only on ARM architectures.
    x86_64 is not vulnerable, x86 is not vulnerable when the SSE2
    instruction set is enabled; but other architectures remain
    vulnerable.
    WebKit Bugzilla: 286694

CVE-2025-24216
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to Paul Bakker of ParagonERP.
    Impact: Processing maliciously crafted web content may lead to an
    unexpected Safari crash. Description: The issue was addressed with
    improved memory handling.
    WebKit Bugzilla: 284055

CVE-2025-24264
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to Gary Kwong, and an anonymous researcher.
    Impact: Processing maliciously crafted web content may lead to an
    unexpected Safari crash. Description: The issue was addressed with
    improved memory handling.
    WebKit Bugzilla: 285892

CVE-2025-30427
    Versions affected: WebKitGTK and WPE WebKit before 2.48.1.
    Credit to rheza (@ginggilBesel).
    Impact: Processing maliciously crafted web content may lead to an
    unexpected Safari crash. Description: A use-after-free issue was
    addressed with improved memory management.
    WebKit Bugzilla: 285643

[Rahul Chandra]

Just to note it here: This release and 2.48.0 seem to require significantly more RAM to build compared to older releases. -j16 takes more than 40GB of RAM to build.

[thomas]

Replying to Rahul Chandra:

Just to note it here: This release and 2.48.0 seem to require significantly more RAM to build compared to older releases. -j16 takes more than 40GB of RAM to build.

Looks like, yes. Seems to be impossible to compile webkitgtk on i686 currently :-(
It shows "virtual memory exhausted" (-j1)

[Bruce Dubbs]

1903.2 Elapsed Time -  webkitgtk-2.48.1
 
md5sum : dce4acd27a743eb4be03ab4a7cd8353f  /usr/src/webkit/webkitgtk-2.48.1.tar.xz
43136 /usr/src/webkit/webkitgtk-2.48.1.tar.xz SIZE (42.125 MB)
1363016 kilobytes BUILD SIZE (1331.070 MB)
SBU=21.875
 
hostname: samwise123
BFLAGS=-j8

This was a gtk4 build @ j8. I was watching memory usage and it touched around 30% (of 64G) a couple of times but I did not watch continuously.

No patches or seds used.

[Douglas R. Reno]

Replying to thomas:

Replying to Rahul Chandra:

Just to note it here: This release and 2.48.0 seem to require significantly more RAM to build compared to older releases. -j16 takes more than 40GB of RAM to build.

Looks like, yes. Seems to be impossible to compile webkitgtk on i686 currently :-(
It shows "virtual memory exhausted" (-j1)

Hi Thomas,

I've managed to work around the issue (at least on a gtk3 build, gtk4 is going to be running here in a second).

CMake defaults to using an optimization level of -O3 when we use CMAKE_BUILD_TYPE=Release. For almost every other package, this is totally fine - but WebKit is a different story. The file that it fails on is named 'GeneratedSerializers.cpp', and it gets generated by a python script in the build tree during the build process and placed at DerivedSources/WebKit/GeneratedSerializers.cpp. GeneratedSerializers is a 3+ MB C++ file with well over 75k lines of code, with thousands of functions in it, and which includes hundreds of headers.

I observed it running out of memory as well, but what I found interesting was that on 64-bit systems, the compilation of that file will take well over 8GB of RAM, which is enough to drain 64-bit users who are even running with 24GB of RAM (in the case of my old development system where I tested this). I was in *swap* with 24GB of RAM at -j8.

-O3, while it might produce highly optimized code, is extremely memory and computationally intensive.

To work around this I added the following option to CMake:

-DCMAKE_CXX_FLAGS_RELEASE="-O2 -DNDEBUG"

Note that you need -DNDEBUG for the JIT compiler to build correctly, otherwise it will FTBFS. It looks like Evolution also requires this.

One thing I found interesting is that if I specified CXXFLAGS="-O2 -DNDEBUG" to CMake using -DCMAKE_CXX_FLAGS (or even setting it in my environment), it would get placed in build.ninja for every file... followed by a -O3 later in the line which will supersede the -O2. That is really annoying behavior from CMake.

It looks like Debian at least isn't running into this because they're clearing CMAKE_CXX_FLAGS_RELEASE as part of running CMake, leaving an empty string. That turns off all optimization in general which I really don't think we would want to do. We could use -O1 or -O0 even if we wanted to, but I saw this use 1GB of virtual memory and that was it at -O2 (rather than 3GB+ virtual memory)

Arch uses -DCMAKE_BUILD_TYPE=None which is *definitely* not what we want, and they have received some feedback from CMake's upstream as well about that in the past. In their case it was because of some weird issues with LTO but we don't really use that.

To work around this issue I propose adding -DCMAKE_CXX_FLAGS_RELEASE="-O2 -DNDEBUG" to our CMake line for WebKit.

My reasoning is:

• Reduces memory usage during compilation on x86_64 by ~30%
• Allows this package to get built on i686 again which makes it able to get the security updates.

[Xi Ruoyao]

Or perhaps we can just set -O2 for GeneratedSerializers.cpp (if it does not get in a UnifiedSource-xxxxx.cpp)?

[Douglas R. Reno]

We could try modifying build.ninja for that, but the line number differs between runs of CMake. It gets derived similar to other files in the tree and thus doesn't appear in CMakeLists.txt anywhere that I can set some default flags for it (at least that I've found so far)

On another note, the INCLUDE path is 15,173 characters long for that compile!

[Xi Ruoyao]

Some sort of

sed '/\/GeneratedSerializers.cpp.o.d/,+1{/FLAGS =/s/$/ -O2/}' build.ninja -i

[Douglas R. Reno]

I'll definitely give that a shot!

[ken@…]

Thanks for your (no doubt painful) work on this, guys. Yet another build system which requires insane anounts of real memory and assumes -O3 must be better.

[Douglas R. Reno]

Fixed at f76c067a40f9ec1bae9882b0fcf2012b36548363

This was one of the most painful updates that I have ever done, taking multiple days of experimentation to cut down on RAM usage. I'm hoping that future packages aren't this bad with extremely large generated C++ files that build at -O3 by default (which use 8GB of RAM alone for the compilation).

I've added some text to the page that tells users with less than 16GB of RAM (or on 32-bit systems) to use the -DCMAKE_CXX_FLAGS_RELEASE option as described above.

The security advisory will come with the batch that I need to submit soon, with hopefully the last *current* security update being OpenJDK.

[Douglas R. Reno]

SA-12.3-007 issued.