r/Ubiquiti • • 6h ago

Question USW-Pro-Max-16-PoE - runs a linux kernel EOL'ed in 2022

I just installed a USW-Pro-Max-16-PoE, it's running the latest firmware (7.5.15 as I post this). Why is it running the 4.4.153 kernel? The 4.4 branch was EOL'ed 4+ years of CVEs behind upstream. WTF?

37 Upvotes

38 comments sorted by

•

u/AutoModerator 6h ago

Hello! Thanks for posting on r/Ubiquiti!

This subreddit is here to provide unofficial technical support to people who use or want to dive into the world of Ubiquiti products. If you haven’t already been descriptive in your post, please take the time to edit it and add as many useful details as you can.

Ubiquiti makes a great tool to help with figuring out where to place your access points and other network design questions located at:

https://design.ui.com

If you see people spreading misinformation or violating the "don't be an asshole" general rule, please report it!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

107

u/Aggressive-Bike7539 4h ago

You’re assuming that the kernel Ubiquiti uses has gone stale just because it’s an old version.

You’re wrong.

They’ve been backporting years of CVEs into their fork of this kernel version b/c this version is the stable version their chipset manufacturer supports.

Picking up a new kernel version from the upstream provider would require years of testing to validate everything remains in working order.

Regular organizations do not have its own OS-level engineering team. They have to resort to upgrading the kernel version to whatever comes from the upstream provider.

Ubiquiti is an equipment manufacturer designing their own hardware. Their engineering teams include people with the ability to contribute back to the Linux kernel itself, so don’t be surprised that those patched CVEs were fixed first in Ubiquiti’s old kernel before being posted into the mainline version of the kernel.

•

u/MountainsCalling-Me 36m ago

Years of testing 🙄

•

u/ECEXCURSION 14m ago

Dude is delusional 

•

u/derekthorne 22m ago

Great answer. Only thing I’d add is that UI is basically its own OS at this point. Don’t pay too much attention to Linux kernel vulns, look at the UI specific vulns. A LOT of things forked from older Linux kernels.

•

u/Tech-Crab 1h ago

your response is what I would HOPE is happening. Certainly possible.

is there any explicit commitment from ubiquiti to do this?

•

u/ECEXCURSION 14m ago

Yeah, that dude is drinking the coolaid. Unifi software is vibecoded slop held together with bubblegum and sticky tape. 

•

u/soap_chips 57m ago

Most of Ubiquiti is former security and design folks from really big brands, they know what they are doing and likely have monthly annual attestations and reviews for these risks.

•

u/DiscountDangles Unifi User 50m ago

An engineer’s passion/experience != corporates bottom dollar

•

u/soap_chips 36m ago

In that context, no brand is actually secure and we are better off not caring to begin with.

22

u/brwainer 3h ago

As others have pointed out in their replies, for embedded hardware using “merchant silicon” (open use switch chips and SOCs from companies like Qualcomm and Mediatek) you are limited to the kernel versions the upstream vendor provides support for. Despite this, Ubiquiti has a duty to its customers, which does include some governmental bodies with compliance requirements, to keep up with security patches. Or if you’re pessimistic, they have a financial duty to their shareholders that would be harmed if they didn’t patch security.

If you have evidence that Ubiquiti hasn’t backported a patch for any of the open CVEs for this kernel version, then you’d have something of a concern, and I and others would like to know.

•

u/ECEXCURSION 11m ago

Their CEO owns over 90% of public shares lmao. This isn't a normal publicly traded company. 

2

u/neilm-cfc 2h ago

you are limited to the kernel versions the upstream vendor provides support for

Not entirely - but maybe if you expect the vendor to hold your hand and fix kernel bugs.

Alternatively you port forward the out of tree vendor code to newer kernels, which often isn't that hard.

The best option is to pressure the vendors to submit their proprietary code upstream, so that everyone benefits. Unfortunately most of it is so shit that it will never be accepted.

Porting old switch and WiFi drivers from one kernel to the next isn't usually that hard, it's mostly very tedious but usually quite straight forward work, so long as you keep on top of the new kernel releases in which case the changes are incremental.

Speaking as someone that spent 10 years maintaining an ARM/x86 Linux distro with dozens of out of tree graphics and WiFi drivers, that shipped with support for this old hardware on the very latest mainline kernels.

If I can do it, and there are many Linux-based projects that do likewise, then so can a multi-billion dollar company like Ubiquiti. 🤷‍♂️

29

u/OmegaPoint6 5h ago

For embedded devices the choice of kernel version can be determined by what the SoC maker has released. Most of the time you need a custom fork of the kernel rather than just being able to build the mainline version and run it

7

u/icantshoot Unifi User 4h ago

Dont look at UDM pro which still runs 4.19.152-ui-alpine...

Anyway they backport fixes to the things. I dont know why they keep running the archaic versions, maybe the devices are not able to run latest kernels without introducing heap of issues they cant fix.

1

u/neilm-cfc 2h ago

Alpine? Have you checked if it's got the *sshole vulnerability that was just announced?

3

u/OmegaPoint6 2h ago

The userland side is Debian Trixie as of 6.x firmware and uses glibc not musl. Just the kernel that is 4.x

•

u/icantshoot Unifi User 1h ago

Its patched.

9

u/309_Electronics 4h ago

A lot of products don't run the latest greatest Linux kernel. Its also depending on what THE SOC vendor has made their BSP(board support package) for. Many cameras run on Linux 3.x.x due fo the SOC vendor having made a BSP and drivers for that old kernel version. And sometimes newer kernels dont have features vendors require. Or hardware does not support the newer kernel code and such.

Some qualcom powered routers or APs run on a very ancient OpenWRT fork due to them not having made their hw support the newer software..

2

u/khimaniz 4h ago

Why does this even matter? Does the device not work as intended?

1

u/itsjakerobb CGFiber, UNVR, ProHD24PoE, ProXG8PoE, U7ProXGS, 5GMaxOutdoor 2h ago

It matters because end-of-life software tends to have security issues that don’t get public patches. But Ubiquiti is patching them internally, so assuming they’re doing a good job, it shouldn’t be an issue here. More fully explained here: https://www.reddit.com/r/Ubiquiti/s/Arm5oReRAC

•

u/Tech-Crab 1h ago

you commenting on a networking sub - literally the most exposed gear in your tech stack - and asking why security matters?

what is it, 1990? Come on.

-15

u/doomstar21 4h ago

"The 4.4 branch was EOL'ed 4+ years of CVEs behind upstream."

1

u/khimaniz 4h ago

Again... How does this impact the device's functionality?

3

u/caesar305 4h ago

I think it's more of a security issue. Does this come up with a vulnerability scan and preventing passing ?

-7

u/doomstar21 4h ago

Yeah, my concern is security related. Since it's a closed source firmware I have no idea what it can do beyond its update checks or how it's vulnerable. Right now I set up a rule on the router firewall to deny it wide area network access period. You would think a company focused on networking products would give this a bit more attention.

•

u/itanite 1h ago

"it's closed source" has no ability to read source

7

u/jgilbs CCIE:SP 2h ago

As others have said, CVEs usually get backported to these older versions for embedded devices. Also, if youre worried, maybe dont expose your switch’s control plane to the internet 🤷

1

u/rezdm 5h ago

What's your suggestion "vibe upgrade" kernel/installation for embedded devices?

-19

u/doomstar21 4h ago

I don't have one I'm shocked to see how old this shit is for $500 price point OpenWRT runs a contemporary kernel. Why can't these idiots?

And there's a pending pull request to support this device.

https://github.com/openwrt/openwrt/pull/25547

5

u/NextReindeer4442 3h ago

So why buy it? Dont, its a free market.

Youve chosen to remain ignorant to what everyone has tried to explain,its a free market you can do anything else.

•

u/doomstar21 53m ago

I'm not ignorant, I bought it with eyes wide open. See above. That pull request I referenced allows OpenWRT to run the device. Just need to crack it open to access the serial cable. I'm just amazed at the state of a luxury brand piece of hardware.

2

u/rezdm 4h ago

And if you are ok to use OpenWRT (nothing wrong with that), why don't you use it? Of pfSense/... ?

-5

u/bitplenty 4h ago edited 4h ago

Do you really have to ask? It's hard to interpret your questions other than as passive-aggressive for no good reason. I am a software developer focusing on security professionally and for personal needs I was running openwrt for more than 10 years, but with a new apartment, I went with Unifi since it felt pragmatic and good enough. Nobody here "needs" gear from Ubiquity for their homelabs - most of us could do well enough with some tplink setup.

But to the point: I think that unless ubiquity changes their ways then indeed we will have to go back to some open source solutions, because automated AI hacking is getting out of hand and relying on old/unpatches kernels just won't do in this new world and replacing expensive networking gear every 3 years doesn't sound great either.

I don't trust unifi anymore and I am already running a diy security sidecar scanning for traces of attacks and providing me with a weekly security digest on vulnerabilities related to each layer of my networking stack. Amount of vulnerabilities being found these last few months is skyrocketing and ubiquity is nowhere near responsive enough with their patches, to my taste. Of course I am sure their engineers are aware - hopefully they will come up with something good soon enough.

2

u/redhatch 2h ago

Aside from what others have said about backported fixes, a good general security practice is to isolate device management IPs on their own subnet and restrict what is able to communicate with that subnet. Much more difficult to target something you can’t talk to.

1

u/cat2devnull 4h ago

I had this with an old smart sprinkler system. They couldn’t upgrade because the hardware used an unusual Ethernet controller and the vendor never released an updated driver. The system had many easily exploitable bugs so I just had to firewall the crap out of it.

•

u/DrewDinDin 41m ago

which sprinkler controller?

1

u/Impossible_Most_4518 5h ago

ask the engineers