firefox-128.3.1

[Bruce Dubbs]

New minor version.

[Douglas R. Reno]

Release notes will become available tomorrow

[Douglas R. Reno]

Note that a Thunderbird release is incoming as well.

Security fixes:

• CVE-2024-9392: Compromised content process can bypass site isolation (High)
• CVE-2024-9393: Cross-origin access to PDF contents through multipart responses (High)
• CVE-2024-9394: Cross-origin access to JSON contents through multipart responses (High)
• CVE-2024-8900: Clipboard write permission bypass (Moderate)
• CVE-2024-9396: Potential memory corruption may occur when cloning certain objects (Moderate)
• CVE-2024-9397: Potential directory upload bypass via clickjacking (Moderate)
• CVE-2024-9398: External protocol handlers could be enumerated via popups (Low)
• CVE-2024-9399: Specially crafted WebTransport requests could lead to denial of service (Low)
• CVE-2024-9400: Potential memory corruption during JIT compilation (Low)
• CVE-2024-9401: Memory safety bugs fixed in Firefox 131, Firefox ESR 115.16, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3 (High)
• CVE-2024-9402: Memory safety bugs fixed in Firefox 131, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3 (High)

[Xi Ruoyao]

Douglas: by the way, have you figured out your Firefox crash?

[Douglas R. Reno]

No I haven't :( I originally thought it was on my laptop only, but because you reminded me I checked on my development system and noticed that going to x.com (formerly Twitter) results in the same crash. I'll try it on 128.3.0 and see if it works there.

[thomas]

FF 128.3 seems working stable (here). I'm writing this on a 128.3.0 on i686, with logged in to X on another tab. But i still had to apply a patch for i686:

if [ "$(uname -m)" == "i686" ]; then
    patch -Np0 <<EOF
diff -Naur modules/fdlibm/src/math_private.h{.orig,}
--- modules/fdlibm/src/math_private.h.orig      2024-06-17 14:24:36.163135811 +0200
+++ modules/fdlibm/src/math_private.h   2024-06-17 14:25:44.598839682 +0200
@@ -30,7 +30,11 @@
  * Adapted from https://github.com/freebsd/freebsd-src/search?q=__double_t
  */

+#if defined __FLT_EVAL_METHOD__ && (__FLT_EVAL_METHOD__ == 2)
+typedef long double      __double_t;
+#else
 typedef double      __double_t;
+#endif
 typedef __double_t  double_t;
 typedef float       __float_t;

EOF
fi

[Xi Ruoyao]

Replying to thomas:

FF 128.3 seems working stable (here). I'm writing this on a 128.3.0 on i686, with logged in to X on another tab. But i still had to apply a patch for i686:

if [ "$(uname -m)" == "i686" ]; then
    patch -Np0 <<EOF
diff -Naur modules/fdlibm/src/math_private.h{.orig,}
--- modules/fdlibm/src/math_private.h.orig      2024-06-17 14:24:36.163135811 +0200
+++ modules/fdlibm/src/math_private.h   2024-06-17 14:25:44.598839682 +0200
@@ -30,7 +30,11 @@
  * Adapted from https://github.com/freebsd/freebsd-src/search?q=__double_t
  */

+#if defined __FLT_EVAL_METHOD__ && (__FLT_EVAL_METHOD__ == 2)
+typedef long double      __double_t;
+#else
 typedef double      __double_t;
+#endif
 typedef __double_t  double_t;
 typedef float       __float_t;

EOF
fi

As I've said many times it's incorrect, because it's breaking the upstream expectation of floating point arithmetic.

And it should be unneeded with Clang (but maybe something has changed in Clang 19 or you are passing things like -march=i686 in CFLAGS, note that Clang's default baseline of 32-bit x86 is pentium4).

[thomas]

yes, i do pass -march=i686 -mtune=generic using gcc, not clang. I do not get why that is illegal. Can you explain that?

As the 32bit-OS is running on a VM on a Xeon processor, my idea of passing -march=i686 is to make sure, that 32bit instructions are used regardless what /proc/cpuinfo or something like that says. Maybe this approach is wrong, what should i do instead?

[Xi Ruoyao]

Replying to thomas:

yes, i do pass -march=i686 -mtune=generic using gcc, not clang. I do not get why that is illegal. Can you explain that?

As the 32bit-OS is running on a VM on a Xeon processor, my idea of passing -march=i686 is to make sure, that 32bit instructions are used regardless what /proc/cpuinfo or something like that says. Maybe this approach is wrong, what should i do instead?

Does your Xeon has SSE/SSE2 support? If it has SSE2 you can append "-msse2 -mfpmath=sse" after "-march=i686" (both GCC and Clang should work). If it has only SSE (but not SSE2) you can append "-msse" after "-march=i686" and use Clang.

If it has no SSE at all, unfortunately Mozilla has stopped to support such old processors and there is nothing we can salvage.

It looks to me no living distros still support non-SSE2 i686 today.

[Xi Ruoyao]

IIRC several months ago Douglas and I discussed about setting the GCC default on 32-bit x86 same as Clang (i.e. passing --with-arch=pentium4 --with-fpmath=sse configuring GCC on 32-bit x86).

But it would, obviously, make pre-Pentium-4 processors unsupported. (However to me currently we are already pretending they were supported.)

And we might also need to turn -mstackrealign on by default for GCC (or old pre-built binaries can crash if running with SSE-enabled 32-bit LFS libraries) if we decide to do so.

[Xi Ruoyao]

Replying to Xi Ruoyao:

It looks to me no living distros still support non-SSE2 i686 today.

​AOSC Retro supports i486 but it will emit an error message and refuse to install Firefox if the user attempts to do so on a non-SSE2 CPU.

[Douglas R. Reno]

Now 128.3.1 with a new CVE fix, which is being actively exploited in the wild.

CVE-2024-9680: Use-after-free in Animation timeline

Reporter
    Damien Schaeffer from ESET
Impact
    critical

Description

An attacker was able to achieve code execution in the content process by exploiting a 
use-after-free in Animation timelines. We have had reports of this vulnerability being 
exploited in the wild.

References

    Bug 1923344

[Douglas R. Reno]

Fixed at 657c8a09f53d7ad867f65764d7ef5751376d295d

SA-12.2-023 issued