Ubuntu 20.04.4 LTS Released With Hardware Enablement Stack From Ubuntu 21.10

[nadro]

Yesterday I replaced Ubuntu 21.10 by Fedora 35 (I replaced those OS'es on secondary platform too 2 weeks ago) and I'm really happy with the results. Ubuntu release policy for kernel and Mesa is horrible (glad that we can use ppa) + slow crap named Snap... 2 nice things from Ubuntu? Improvments to Gnome made by Daniel Van Vugt and Yaru theme. I used Ubuntu since 6.06, but in last times they made a lot of stupid decisions and for my it was too much.

[kylew77]

Yesterday I replaced Ubuntu 21.10 by Fedora 35 (I replaced those OS'es on secondary platform too 2 weeks ago) and I'm really happy with the results. Ubuntu release policy for kernel and Mesa is horrible (glad that we can use ppa) + slow crap named Snap... 2 nice things from Ubuntu? Improvments to Gnome made by Daniel Van Vugt and Yaru theme. I used Ubuntu since 6.06, but in last times they made a lot of stupid decisions and for my it was too much.

I've never used vanilla Ubuntu always Xubuntu or Kubuntu, vanilla Ubuntu's insistence of sticking with Gnome 3 was disappointing for people making the switch from Windows. Set my parents up with Xubuntu and labeled the launcher start and put some shortcuts on the desktop and they love it more than Windows XP, been riding the Xubuntu LTS train for them since 14.04. I'm sure this summer or next winter whenever the next time I'm home I will upgrade them to 22.04. Helps that with Wine they can play the same binary spider and hearts game they loved from Windows XP plus lots of new games from the KDE game collection they have gotten hooked on.

[F.Ultra]

I find the acpi/tlp bug quite dramatic. Can someone explain why the kernel has no safeguard for this? Is this again a lousy uefi implementation from the vendor?

What happened was that Kernel 5.13 made lseek mandatory for /proc. Meanwhile acpi_call is a 3d party external kernel module which have been unmaintained for 9 years so it was never patched to support lseek so the Kernel tries to make a function call to NULL. So no this was not due to some uefi shenanigans. And if the kernel would have to check every single function call every time it makes them you would have to pay a quite hefty performance penalty so this is not done, and frankly the Kernel should be able to rely on the modules providing correct structures to it (and no this is not a security hole, if you can load a module into the kernel then you are already in control of the whole system).

[NobodyXu]

What happened was that Kernel 5.13 made lseek mandatory for /proc. Meanwhile acpi_call is a 3d party external kernel module which have been unmaintained for 9 years so it was never patched to support lseek so the Kernel tries to make a function call to NULL. So no this was not due to some uefi shenanigans. And if the kernel would have to check every single function call every time it makes them you would have to pay a quite hefty performance penalty so this is not done, and frankly the Kernel should be able to rely on the modules providing correct structures to it (and no this is not a security hole, if you can load a module into the kernel then you are already in control of the whole system).

I think the kernel could check for NULL in the table when loading the module, either fill it with some dummy default value or reject the module based on policy

[Developer12]

What happened was that Kernel 5.13 made lseek mandatory for /proc. Meanwhile acpi_call is a 3d party external kernel module which have been unmaintained for 9 years so it was never patched to support lseek so the Kernel tries to make a function call to NULL. So no this was not due to some uefi shenanigans. And if the kernel would have to check every single function call every time it makes them you would have to pay a quite hefty performance penalty so this is not done, and frankly the Kernel should be able to rely on the modules providing correct structures to it (and no this is not a security hole, if you can load a module into the kernel then you are already in control of the whole system).

The problem comes when the kernel makes a dump to NVRAM when the null dereference occurs. Normally making a dump is good, but eventually the BIOS NVRAM fills up. It might be good if the kernel only kept the last N dumps, but instead it fills all the space and the badly-programmed bios borks without a means of recovery.