Unfortunately, there are also some running aftermarket firmware builds with the vendor driver, due to it having an edge in throughput over mt76.
Mediatek and their WiSoC division luckily have a few engineers that are enthusiastic about engaging with the FOSS community, while also maintaining their own little OpenWrt fork running mt76.[1]
[1] https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...
In an ideal world, consumers would be happy to pay a premium for a device that's a generation behind in terms of features but has really good firmware. In the real world, only Apple have the kind of brand and market power to even attempt that.
Because those employees cost a lot of money and these commodity widgets have razor thin margins that don't enable them to pay high salaries while also making enough profit to stay in business.
You can pay more to hire better people and put the extra cost in the price of the product but then HP, Lenovo, Dell, et-al aren't gonna buy your product anymore, they're gonna buy instead from your competition who's maybe worse but provides lower prices which is what's most important for them because the average end user of the laptop won't notice the difference between network cards but they do check the sticker price of the machine on Amazon/Walmart and make the purchasing decision on that and stuff like the CPU and GPU not on the network card in the spec sheet.
Vendors plural to worry about:
“…driver bundles used in products from various manufacturers, including [but not limited to] Ubiquiti, Xiaomi and Netgear.”
That said, vendors (plural) say no products use this, e.g. Ubiquiti:
https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
Not sure if you noticed but the OpenWRT 21.02.x series (based on mainline kernel 5.4 series) is affected, and these guys generally know their game when it comes to wireless on Linux. So much so that I think the mainline kernel mt76 driver is actually maintained by an OpenWRT developer.
On the bright side, it doesn't sound like this is in baseband firmware but instead in a "value add" service that isn't 100% necessary to the functioning of the WNIC itself.
This reminds me of how some devices come with driver packages that include not just the actual driver software that's usually tiny and unobtrusive, but several orders of magnitude larger bloatware for features that 99% of users don't need nor want. Printers and GPUs are particularly guilty of this.
I've done some Android development so let me translate that for you: "layers upon layers of dog shit APIs"
I have a device with a mt6631 wifi chip and I'd assume it's unaffected just because it's not mentioned as affected anywhere, but it's hard to tell where it might fit into the lineup.
https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
There are vulnerable drivers for some chipsets used by UBNT hardware, but they have zero products that use those drivers.
AMD decided to brand Mediatek's MT7921 and MT7922 as RZ608 and RZ616 to have something to sell to OEMs at the same price point as Intel's xx1 chips.
I've had sequentially an Intel and an AMD ThinkPad for work (I killed the first one). Turns out, the wifi is much much better on the AMD one with the MediaTek chipset than on the Intel one with the Intel chipset. On the latter, I had very frequent disconnects from the network (severals per hour) along with atrocious latency even on 5GHz. And by atrocious latency, I mean atrocious as in "it is more than noticeable when using ssh". The current one has been rock solid for the past two or three years.
So yeah, I guess it really depends. The specific chipset I have is a MT7921 and I'm running Linux, YMMV. And it also may depend on the laptop itself.
No idea how WiFi is done on a phone though. Is there a way to find out whether the phone is affected? I hardly ever use WiFi because I have unlimited cellular data and good coverage, but would still be good to know.
ls /sys/module
https://news.ycombinator.com/item?id=23341711
Today it's giving way to "useless use of su" where admins aren't aware of sudo(8) options like "-s" or "-i"
No matter what the software says, or what keys it has set, the hardware should still be hard-configured to honour regional power output limits. This could be something like a block of DIP switches under the cover, so if a user unbolts the case, finds the switch, and toggles it to some country with looser requirements, it's obviously going against manufacturer advice and washes their hands of liability.
> The vulnerability resides in wappd, a network daemon included in the MediaTek MT7622/MT7915 SDK and RTxxxx SoftAP driver bundle.
OpenWRT doesn't seem to use wappd though?
When you see actors at this level set up manufacturing thousands of explosive filled devices at very high production quality, inserting some compromised things like printers or routers in a company network wouldn't be and shouldn't be a surprise.
It is a broader ecosystem problem that there almost no incentive to write secure code. Security is an afterthought like documentation.
Really? I think an extraordinary claim like "eliminating a whole class of problems makes applications no more secure in general" should also come with extraordinary evidence.
Can we stop with the snide comments now please? They're not helpful.
> According to Kryptowire, Adups engineers would have been able to collect data such as SMS messages, call logs, contact lists, geo-location data, IMSI and IMEI identifiers, and would have been able to forcibly install other apps or execute root commands on all devices.
https://www.bleepingcomputer.com/news/security/android-adups...