Skip to content

[pull] master from buildroot:master#1080

Merged
pull[bot] merged 6 commits into
mir-one:masterfrom
buildroot:master
Jul 5, 2026
Merged

[pull] master from buildroot:master#1080
pull[bot] merged 6 commits into
mir-one:masterfrom
buildroot:master

Conversation

@pull

@pull pull Bot commented Jul 5, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

airtower-luna and others added 6 commits July 5, 2026 14:07
The workaround in 3d06661 for the
broken C23 check was incorrect: When overriding ac_cv_prog_cc_c23 the
value must either be "no" (to indicate that C23 is not supported) or
contain the command line parameters to enable C23 with the C compiler
in use (e.g. "-std=gnu23", may be an empty string if appropriate). The
workaround set it to "yes" for host GCC >= 14, making builds fail.

However, the original issue was that apr may try to enable C23 in host
CC calls if the target CC supports it. So instead of figuring out the
correct arguments for GCC >= 14, we can set ac_cv_prog_cc_c23=no only
for host GCC <= 13 and leave it unset otherwise, as in that case
enabling C23 will do no harm.

Fixes: 3d06661
Fixes:
- https://autobuild.buildroot.net/results/77c/77cd5456169e04c2f92dc328c4b6828513d1195f/
- https://autobuild.buildroot.net/results/7a4/7a4fb2b21027f98df607871d9fe0dd234d44aebb/
- https://autobuild.buildroot.net/results/a6c/a6cef4c5965fdeb40d3b39cbd40941329f4fc1c8/
(and more)

Tested-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Dick Olsson <hi@senzilla.io>
Signed-off-by: Julien Olivain <ju.o@free.fr>
UEFI platforms with a Devicetree have recently gained support for some form
of network booting. [1][2]

On those platforms, the UEFI firmware downloads the disk image over the
network and presents it to UEFI applications using the simple filesystem
protocol. This is sufficient for OS loaders such as e.g. GRUB to find their
configuration and load the kernel image.

The firmware must also describe the ramdisk to the OS, so that it finds its
root filesystem. On ACPI based platforms this is done with an NVDIMM
Firmware Interface Table (NFIT). On Devicetree based platforms, this can be
done with a pmem node. [3]

Add a kernel config fragment to add pmem support, which enables network
boot on UEFI platforms with Devicetree.
Also, briefly mention that we support this scenario in the readme.

This can be tested on Qemu, with the following procedure:

Build aarch64_efi_defconfig in a folder, to obtain output/images/disk.img,
and serve the image over HTTP with python:

  $ python -m http.server -d output/images/

In another terminal and another folder, configure a U-Boot based firmware
starting from qemu_aarch64_ebbr_defconfig, and with the following
additional configurations:

  BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2026.04"
  BR2_TARGET_UBOOT_NEEDS_DTC=y

Add the following U-Boot configurations to
board/qemu/aarch64-ebbr/u-boot.fragment:

  CONFIG_EFI_HTTP_BOOT=y
  CONFIG_NET_LWIP=y

Build everything; you should obtain output/images/flash.bin.

Start Qemu as per board/qemu/aarch64-ebbr/readme.txt, but omitting the hd0
-device and -drive stanzas.
U-Boot should start; interrupt it with enter.

At U-Boot prompt, type the following commands:

  => setenv loadaddr 0x43000000
  => efidebug boot rm 0
  => efidebug boot add -u 0 net http://10.0.2.2:8000/disk.img
  => efidebug boot order 0
  => bootefi bootmgr

U-Boot should download the disk image over HTTP and boot Linux with UEFI.
Look for the following message in Linux boot log, to confirm that it did
indeed mount its rootfs from the downloaded image:

  EXT4-fs (pmem0p2): mounted filesystem ...

Link: https://www.linaro.org/blog/installing-fedora-with-uefi-http-boot/ [1]
Link: https://docs.u-boot-project.org/en/latest/develop/uefi/uefi.html#uefi-http-boot-using-the-legacy-tcp-stack [2]
Link: https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/http-boot/pmem_node.md [3]
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Dick Olsson <hi@senzilla.io>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/

Fixes CVE-2025-15661, CVE-2026-55199 & CVE-2026-55200.

Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This version fixes boolean usage for musl toolchains:

Use <stdbool.h> whenever possible to work around musl libc incorrectly
defining __bool_true_false_are_defined.

Fixes:

https://autobuild.buildroot.org/results/5719bb7f5bd709cebc8012341c0b448a8fec3aba/

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Release notes:

https://webkitgtk.org/2026/06/02/webkitgtk2.52.4-released.html

Fixes the following security issues:

https://webkitgtk.org/security/WSA-2026-0003.html

Includes fixes (among others) for CVE-2026-28847, CVE-2026-28883,
CVE-2026-28901, CVE-2026-28902, CVE-2026-28903, CVE-2026-28904,
CVE-2026-28905, CVE-2026-28907, CVE-2026-28942, CVE-2026-28946,
CVE-2026-28947, CVE-2026-28953, CVE-2026-28955, CVE-2026-28958,
CVE-2026-43658, and CVE-2026-43660.

Also added 0001-REGRESSION-313606-main-Fails-to-build-with-system-ma.patch,
to get webkitgtk compiled when -DUSE_SYSTEM_MALLOC=ON is in use.

Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
[Julien: add "security" in commit log title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
@pull pull Bot locked and limited conversation to collaborators Jul 5, 2026
@pull pull Bot added the ⤵️ pull label Jul 5, 2026
@pull pull Bot merged commit 013612b into mir-one:master Jul 5, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants