Critical Problem Notification for GL-MT2500/GL-X3000/GL-XE3000

Just curious what the changes are for the Mediatek uboot code - is this localized to these very targets, or does this also impact targets like MT6000?

Hello @MarcusRumpenstein @doczenith1

If, after updating the X3000 as per the instructions at the top, the Port and Protocol details on the cellular settings page are incorrect, the device may be running an old hardware version.

It's recommended to download the new bootloader from the link below, update the U-boot and firmware version and try again
https://fw.gl-inet.com/firmware/x3000/uboot/uboot-x3000-20250328-2c152d7aad44678ec7411b551ce5c7b0.bin

GL-X3000
I downloaded the latest firmware
I've not updated uboot separately
Cellular data show correct info. Do I have the old hardware? I don't have any way to hook up to the Lan/wan port to my Chromebook or phone so installing uboot separately isn't an option. I can only use the USB port which I'll assume doesn't work for uboot. Bought July 10, 2023 from Amazon USA
What would it cost to trade-in?

This uboot image cold bricked my Brume2 from the Beta test period, I will not recommend this upgrade to anyone attempting to, unless it was expected to fail due to small hardware revision changes I'm not aware of.

Fyi, I attended to http://192.168.1.1/uboot.html and uploaded the image, after the reboot prompt no leds went on, and I assume full brick.

atleast gl team could have test this... this posting is almost a week old.

1 Like

This is my same situation. Brume2 from beta tester period and no led after reboot.

1 Like

In 2025, multiple vulnerabilities discovered in 2024 have been disclosed in U-Boot. Abusing the filesystem support feature (ext4, SquashFS) of U-Boot by manually modifying filesystem data structures, an attacker can cause an integer overflow, a stack overflow or a heap overflow. As a result, an attacker can perform an arbitrary code execution and bypass the boot chain of trust. These issues are mitigated by the version v2025.01-rc1

Because of the above, please may someone please confirm the version of this new U-Boot.

@ChrisW have you asked for the new U-Boot GPL sources yet?

Hello,
@xize11 @antifascista

Very sorry for this issue.

We flashed this uboot and firmware by repeatedly test rigorous on multi-model to ensure that they work properly in line with expectations.

  1. Can it enter the uboot and access 192.168.1.1/uboot.html?

  2. If it can, please re-flash the uboot file and firmware again to see if it can be restored.

  3. If no luck, please contact [email protected] and our support team will properly resolve it for you.
    Please cite this comment/post, and provide router MAC and order number in the email, we need to return the router to the factory to check if re-flash and it cannot be restored.

As or Brume2, please firstly upgrade the U-Boot bootloader itself, then upgrade the new firmware. Both the two upgrade can be made via the uboot interface.

I think you have noticed the video.
The way to upgrade the U-boot bootloader and use uboot to debrick the router is very similar.
The differences is just, when flashing U-Boot bootloader, you shall access 192.168.1.1/uboot, but when flashing firmware, you shall access 192.168.1.1

Only these models, No impacts for MT6000

Sorry but we missed that issue at that time.
The hardware version is hard to verify as you will need take apart the case.

Only very few old X3000 has this issue.
Please use the U-Boot version in the first post and identify the issue as Cathy mentioned.

H Philip, I'm not running the GL-iNet u-boot on my X3000 in any case: I just have the vanilla upstream u-boot from GitHub - u-boot/u-boot: "Das U-Boot" Source Tree with an appropriate device tree, and tend to track upstream pretty closely so I pick up the fixes more or less as they commit them.

But I'm curious about the specific hardware difference between early X3000 and later X3000 @alzhao @rain - any chance of commenting on what it is? (Some difference that affects the device tree presumably?) I'm just wondering if I need to add something to the OpenWRT documentation for u-boot on this router to warn users running OpenWRT u-boot that they need to check...

2 Likes

By the way, I wouldn't get too excited about the impact of the security issues that have been patched in u-boot, although they were a really interesting piece of research.

If you want to see the kind of thing we're talking about, one that was interesting for me was in u-boot ext4: ext4: Fix integer overflow in ext4fs_read_symlink() · u-boot/u-boot@35f75d2 · GitHub, but there were similar integer overflow issues in the squashfs and erofs u-boot code.

Although I do load my kernels from an ext4 /boot so I'm theoretically impacted, I think both GL-iNet and standard OpenWRT use raw partitions for kernels so wouldn't use these parts of u-boot or even mount filesystems there at all.

And the second question you have to ask is: what security mechanisms do these vulnerabilities in u-boot allow you to bypass? In each case, they allow a user with root access to the running Linux system on the router to hand-craft an evil filesystem image that allows arbitrary code execution in the context of the bootloader when that filesystem is accessed. There are trusted boot systems where this allows you to bypass kernel signature checks that would otherwise be performed by the bootloader.

But these consumer routers are not that kind of system. The running kernel can already scribble over u-boot and replace it with whatever code it likes, so the exploit doesn't add any new abilities on top of those the root user already had.

To be clear, though, the 'fixes for the fix' described in the original GL-iNet post at the top of this thread are different - it sounds like the previous u-boot update leads to excessive (flash?) wear on some devices, and if I'm right that's what's happening, it's quite important to fix promptly if you don't want to shorten the lifetime of the device. Heavily writing eMMC is Bad News.

1 Like

I think not. We improved the time sequence with some minor hardware changes.

Thanks! Good to confirm I don't need to update anything on the OpenWRT side.

I can confirm that my x3000 (ordered 11 May, 2023) worked just fine with the U-Boot version in the first post. I have not tested with a sim card but the Protocol and Port displayed as Cathy specified in her post.

nope it is completely dead for me.

well I don't have a order number since it is a beta model, but would it be to any use to sent the sample back for research purpose?

Now I have a dead GL-MT2500. Completely dead, no lights, nothing. Started to upload the bootloader, waited, and waited and nothing. What is the point of this exercise? I need this to be working now. I have a second GL-MT2500 that now I wont touch.
What am I supposed to do now?

4 Likes

I wrote mail to support.
thanks