firefox140: update to 140.11
Mozilla Foundation Security Advisory 2026-48
Security Vulnerabilities fixed in Firefox ESR 140.11
Announced
May 19, 2026
Impact
high
Products
Firefox ESR
Fixed in
Firefox ESR 140.11
#CVE-2026-8946: Incorrect boundary conditions in the Audio/Video: Web Codecs component
Reporter
zx
[221 lines not shown]
[CIR] Fix problem with multiple references to an alloca in a cleanup (#198928)
A recent change to hoist allocas out of a deferred cleanup scope had a
bug wherein if multiple entries in the deferred cleanup stack referenced
the same alloca, the second attempt to see if it needed to be hoisted
would assert in the MLIR region code. This was happening because when we
hoist the alloca, we hoist it to a block that is still under
construction. On the second encounter when we're walking its parent
chain to see if it is contained within the cleanup scope we're
processing, our call to get the parent region of the block containing
the alloca would assert because the alloca is in an unlinked block (it
gets added to a region after we're done constructing it).
To fix this problem, I changed the way we're checking for the alloca
being nested within the cleanup scope, using a more robust
implementation that will tolerate encountering unlinked operations.
Assisted-by: Cursor / claude-opus-4.7-thinking-xhigh
clang/AMDGPU: Use TranslateArgs from the base toolchain instead of the host
This fixes -Xopenmp-target / -Xarch for arbitrary arguments. HIP and OpenMP
had cargo-cult broken implementations of TranslateArgs, which called the host
toolchain's implementation, and then special case transferred either -march
or -mcpu to the device argument list. The respective device forwarding flags
should work for any argument, not just this one. The main feature that needs
to be preserved is the shared filtering of unsupported sanitizers to degrade
them into warnings.
Most of the changes here are dealing with fallout observed when
the host target is darwin. The darwin toolchain happens to have
some hacky statefulness tracking the compile target version, which
gets written and rewritten on argument parsing. To maintain this hack,
there are a few unused calls to getArgsForToolChain; start passing OFK_Host
to these so the offload toolchains don't get confused and think they're in
a non-offload context.
clang: Refactor handling of offload sanitizer arguments
Previously the AMDGPU toolchains hackily handled -fsanitize arguments.
They would lie and report that all host side sanitizers are available,
then TranslateArgs would filter out the device side cases that do not
work, providing diagnostics for the skipped cases. Move that logic
into the base sanitizer argument parsing.
This makes the produced diagnostics more consistent. Previously we
would get repeated warnings when a sanitizer is fully unsupported
by amdgpu, which should now be once for the toolchain. These could
be further improved; we're printing the specific field of -fsanitize
in more cases where it could be skipped. In other cases we have the
opposite problem, where we aren't reporting the exact sanitizer
from the -f flag in the case that depends on a subtarget feature.
This will help fix other broken target specific flag forwarding bugs
in the future.
Co-authored-by: Claude Sonnet 4 <noreply at anthropic.com>
clang: Add BoundArch/OffloadKind argument to getSupportedSanitizers (#196503)
Currently the AMDGPU HIP and OpenMP toolchains falsely report
all host sanitizers are supported, and then go out of their way
to skip forwarding those to the device compiles. Add an offloading
kind argument so that in the future this can be handled in one
place in the base toolchain.
Co-authored-by: Claude Sonnet 4 <noreply at anthropic.com>
postfix: suggest sasl option
This only allows the cyrus-sasl functionality in postfix. It still
needs to be administratively enabled in postfix, with Cyrus SASL
mechanisms installed seperately.
[RISCV][P-ext] Return SDValue() instead of calling DAG.UnrollVectorOp for non-splat shift amounts. NFCI (#198914)
The generic legalizer can call DAG.UnrollVectorOp itself.
[PowerPC] set libcall lowering for fp setcc ops on SPE boards (#153238)
SPE fp comparison instructions don't comply with IEEE-754. They treat
special values like NaN and Inf as normalized numbers, which leads to
incorrect results. For example, when comparing NaN with a normal, the
result can be true, even though the standard requires comparisons with
NaN to be false.
This patch fixes the issue by lowering these operations to libcalls. SPE
comparison instructions can still be used when fast-math flag is
enabled.
