Why is your Linux Kernel so old?

Chimpans · December 29, 2024, 7:58pm

Every GL-iNet router has old kernels.

Flint 2:

root@GL-MT6000:~# uname -a
Linux GL-MT6000 5.4.238 #0 SMP Thu Dec 5 01:20:08 2024 aarch64 GNU/Linux

That kernel was released March 2023, which is 648 days ago!!

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.238

It's a LTS (Long-Term-Support) kernel. The whole purpose of those kernels is that they will only backport CRITICAL security patches to it. And that it will be a very stable kernel.

There have FIFTY new security releases for the 5.4 LTS kernel in the past NEARLY TWO YEARS that GL-iNet has been ignoring.

The latest kernel is 5.4.288

https://www.kernel.org/

Please update your LTS kernels in your GL-iNet firmwares. Do a better job with this. Customers deserve a better job with this.

Chimpans · December 29, 2024, 8:01pm

Let's remember that you recently had a big security problem in August: Security Advisories (Vulnerabilities and CVEs) August 1 2024 - GL.iNet

Having old kernels is a bad idea which makes the security of your routers weaker.

Renato · December 29, 2024, 8:02pm

Check this version: 4.7.0-op24

Renato · December 29, 2024, 8:06pm

Which firmware version are you using?

Chimpans · December 29, 2024, 8:53pm

@Renato I am using the latest firmware of course. This is why I didn't mention the version.

https://dl.gl-inet.com/router/mt6000/stable

4.7.0.

It uses a nearly 700 days old Linux kernel. Really bad.

By the way, do not use the -op24 variant. It uses snapshot of openwrt which is unstable, and it uses the open source Mediatek drivers which have high WiFi latency and reports of router hanging/needing restart because WiFi becomes slow. They mention these problems on the official download page for op24. I hope the open source drivers become good next year, then I may consider it.

Renato · December 29, 2024, 9:07pm

Do you know the patches they have applied in their firmware?

The Kernel is from 2 years ago, but their latest firmware is 23 days old.

Chimpans · December 29, 2024, 9:08pm

I really do not care. They should use the latest LTS kernel and then add their own patches on top. They should not maintain their own outdated kernel fork. I say this as a Linux developer who has contributed code to the kernel. Just update to the latest LTS release. It is the whole point of LTS: Making it painless to use the latest LTS release since they only allow non-breaking changes.

Yes their firmware was released 23 days ago and uses a 700 days old kernel release. It is shameful since LTS kernels are drop-in compatible.

Renato · December 29, 2024, 9:13pm

If you don't care, you should not assume they are using a plain Kernel without any patches.

Their firmmware is frequently maintained on the same way the LTS is maintained.

If you prefer a brand new kernel, so 4.7.0-op24 is also available. You are free to choose.

Chimpans · December 29, 2024, 9:15pm

Nah op24 is not a replacement for the official firmware. I already explained this.

And they can add their own patches to the latest LTS kernel. I explained this too. It is not a brand new kernel. LTS is an old kernel on purpose, where each new release is drop-in compatible. LTS kernels only get security patched and critical fixes. This is why it is shameful that they do not update to the latest version of the LTS kernel they are on.

I am now waiting for their official response about why their kernel is 700 days old. Not arguing with a user.

Renato · December 29, 2024, 9:18pm

Official firmware is what you can find in their official download page.

Do you have any bug that was fixed on LTS Kernel and it's not fixed on GL-iNet firmwares?

Chimpans · December 29, 2024, 9:23pm

The top of the page explains why the OpenWRT is not the official firmware. It just an afterthought, a build of OpenWRT 24 from snapshot for those who want to try the latest OpenWRT and don't mind the buggy open source WiFi driver and the bug risks that come with OpenWRT snapshots:

https://dl.gl-inet.com/router/mt6000/open

Heading to bed now.

Renato · December 29, 2024, 9:31pm

I never said to you to use OpenWRT firmwares.

The official firmware is that one you can find in GL-iNet website.

It's not a plain OpenWRT and it's not a plain Kernel.

You can not assume that GL-iNet is using plain snapshots versions without any patch applied.

By the way, I'm using their beta 4.7.0-op24 without any problem.
If you have any problem, share your logs with GL-iNet.

gfondeur · December 29, 2024, 10:29pm

Because you don't care and are unaware of the advantages 4.x.x-op24 bring to the table you should return your GL.iNet routers and get something else

Chimpans · December 30, 2024, 2:36pm

I might have used OpenWRT 24 snapshot if the Mediatek open-source driver was good. It's not good. It's a known issue with op24. GL-iNet literally mention it at the top of the page I just linked. And there's been thousand-post long threads about it. The open-source Mediatek driver is buggy. And since I bought it primarily as a WiFi router for VR, installing op24 would be stupid.

Renato · December 30, 2024, 2:55pm

So just stay with the Firmware 4.7.0 from Dec/5th

Do you have any issue with this 4.7 firmware (Kernel 5.4.238) that has been fixed on LTS Kernel 5.4.288?

Chimpans · December 30, 2024, 3:29pm

Yes, all of these security exploits and critical bugs have been fixed in the nearly 700 days that have passed:

azleatherneck · December 30, 2024, 3:53pm

Umm, ha “Coder” its the closed source drivers. MT hasn't updated them to be compatible. Are you any good at coding or just flapping your gums

Renato · December 30, 2024, 3:53pm

This is not how things work, buddy.

For example:

From 5.4.238 to 5.4.253 there are 2 security bugs:

commit 66a6d704c251aac864b69ae094a7579e0837eec9
media: dvb-core: Fix kernel WARNING for blocking operation in wait_event*()
CVE-2023-31084

commit bc7b9a6c2ca42b116b0f24dbaa52b5a07d96d1d6
xen/netback: Fix buffer overrun triggered by unusual packet
CVE-2023-34319

Do you believe these bugs applies to GL-iNet hardwares?
Do you believe these modules are compiled into GL-iNet firmwares?

When a security bug is discovered and it APPLIES to their product, a new security update is released

About non security bugs, let's pick another random example:

commit 8b0ecf2167a05d24f153efd7cf31a76dbb32fdda
tty: 8250: Add support for Intashield IS-100

Do you believe this also applies to GL-iNet hardware?

packetmonkey · December 30, 2024, 4:48pm

You really don't seem to understand how things work in the linux kernel. Security updates are backported all the time by all the major distributions, including OpenWRT and gl-inet's version of it.

Chimpans · December 30, 2024, 5:12pm

Please... listen... There is nothing preventing GL-iNet from using the latest LTS 5.4.x kernel. I have already explained this to you. It is the whole point of LTS kernels: Upgrading is painless, because new releases only contain security patches and critical bug fixes. The LTS kernel itself IS the backport kernel: The Linux kernel developers freeze a specific branch, won't add any new features, and will only backport security fixes/critical bug fixes to it. That's the whole point. You should not duplicate their effort. And if you have done some custom patches, the good and correct thing to do is to apply them (rebase) to the latest LTS kernel.
CVE references found in the changelogs released in the 700 days since GL-iNet's old kernel (and this doesn't count any of the other exploits which have been discovered and patched before any CVE was assigned):

rg -i cve
ChangeLog-5.4.259
2332:    This change is used to relieve CVE-2020-26555. The description of
2333:    the CVE:
2359:    Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
2375:    This change is used to relieve CVE-2020-26555. The description of the
2376:    CVE:
2405:    Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]

ChangeLog-5.4.281
41:    CVE: CVE-2024-41090
77:    CVE: CVE-2024-41091

ChangeLog-5.4.273
4016:    This patch is against CVE-2023-6270. The description of cve is:
4035:    Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270

ChangeLog-5.4.258
54:    This is XSA-441 / CVE-2023-34324.

ChangeLog-5.4.285
369:    Link: https://lore.kernel.org/all/2024100904-CVE-2024-47663-9bdc@gregkh/
3409:    [ Sherry: bp to fix CVE-2023-52530, resolved minor conflicts in
5056:    [Sherry: bp to fix CVE-2024-38544. Fix conflict due to missing commit:
6625:    Alfred Agrell found that TOMOYO cannot handle execveat(AT_EMPTY_PATH)
6627:    commit 51f39a1f0cea ("syscalls: implement execveat() system call") missed
6641:    Fixes: 51f39a1f0cea ("syscalls: implement execveat() system call")
6772:    For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential
6789:    Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270

ChangeLog-5.4.255
3012:    This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit

ChangeLog-5.4.246
1489:    CVE-2023-31084 was assigned to this bug.
1495:    Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-31084

ChangeLog-5.4.266
143:    This fixes CVE-2023-6606.

ChangeLog-5.4.288
52:    This is XSA-465 / CVE-2024-53240.

ChangeLog-5.4.270
1949:    This is similar to CVE-2022-3061 in i740fb which was fixed by
1973:    This is similar to CVE-2022-3061 in i740fb which was fixed by

ChangeLog-5.4.252
44:    This is CVE-2023-34319 / XSA-432.

ChangeLog-5.4.253
864:      (CVE-2023-1076),
904:      (CVE-2023-1076),
2037:    In the QFQ scheduler a similar issue to CVE-2023-31436
2062:    Similarly to CVE-2023-31436, "lmax" is increased without any bounds
2073:    As a result the same issue as in CVE-2023-31436 can occur, allowing heap
2613:    Documentation: security-bugs.rst: clarify CVE handling
2617:    The kernel security team does NOT assign CVEs, so document that properly

ChangeLog-5.4.257
10506:    Fixes: CVE-2023-1989
10511:    [ Denis: Added CVE-2023-1989 and fixes tags. ]

ChangeLog-5.4.274
2591:    This patch fixes CVE-2024-24858 and CVE-2024-24857.
2598:    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24858
2601:    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24857
6652:    This is the candidate patch of CVE-2023-47233 :
6653:    https://nvd.nist.gov/vuln/detail/CVE-2023-47233

ChangeLog-5.4.268
1788:    This is XSA-448 / CVE-2023-46838.

ChangeLog-5.4.263
2685:    This addresses the disclosure CVE-2023-25775.

ChangeLog-5.4.262
4529:    This fixes CVE-2023-28464.

ChangeLog-5.4.287
9740:    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49974