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.
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.
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.
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.
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:
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.
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.
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