[06:55] dsmythies, you can build your own config. there's only very few differences to the generic config: https://paste.ubuntu.com/p/CRsnYKtnMf/ [06:56] and https://kernel.ubuntu.com/~kernel-ppa/config/jammy/linux/5.15.0-16.16/ === vorlon` is now known as vorlon === tjaalton_ is now known as tjaalton [10:31] I'm sorry, but can someone explain to me, why 0d21e6684779493d90f3dee90d4457d5b4aed8ad just now got released via ubuntu security update (CVE-2021-39698)? That Commit is from december and does mention "use after free", which is very verbatim for Linus. aren't there automatic scripts scanning commit messages at Canoncial? [10:31] In aio_poll_complete_work of aio.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-185125206References: Upstream kernel [10:33] or is that due to androids security process? I don't know much about it tbh. This is USN-5337-1, for reference. But 3 months to patch is rather long, imho (I know it's hard for all distros, giving upstream obfuscates commit messages on purpose). [11:38] for some kernels, they have been applied for two months, but only got released last month, for 5.13 kernels, it took one extra cycle [11:38] we do prioritize CVEs, that is, some CVEs have a higher priority than others [11:39] and there is a need to test the kernels as well, so it's a matter of balancing that [11:41] we could be tracking commit messages a little better. right now, we rely mostly on CVEs to track these, and this one in particular has only been disclosed by Android on their March bulletin [11:41] because of the great work of upstream stable that we track, we were able to have it fixed even before the CVE was disclosed [13:46] cascardo: thanks for the info; as I said I have some understanding that it's hard to track. good to know that you are also doing your own testing :) [13:47] I still wish upstream had a better/more transparent way of disclosing vulns (not hiding cve's from commit messages) :/ [14:36] juergh, Than you. I admit I had not recently checked the differences between generic and low latency kernel configurations. There used to be many mnay more differences. I assume the answer to "will there be a low latency mainline PPA?" is no. === RikMills__ is now known as RikMills [16:12] I'm figuring out how to best report a kernel bug (something broke upgrading from 5.4.0-100 to 5.4.0-104). I found this page: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies - which implores me to test the latest development kernel. [16:13] I'm happy to do that, but have a hard time figuring out how. I found this: https://wiki.ubuntu.com/Kernel/Dev/KernelTesting - but that seems out of date, I can't add the ppa [16:13] The user named '~kernel-ppa' has no PPA named 'ubuntu/pre-proposed' [16:41] gmc_, if you can enable -proposed, there is 5.4.0-106 there [16:44] gmc_, but given the changes between 5.4.0-100 and 5.4.0-104 are only security fixes, I would be interested to know what broke for you. what arch/platform is it? and was linux-modules-extra-5.4.0-104-generic installed> [17:54] suspend/resume broke... I don't have too much information currently, I'm in the middle of emigrating which sucks up a lot of time. But with -100 closing the lid and opening it does the correct thing [17:54] but with -104 closing and opening results in a fresh boot [17:55] ii linux-modules-extra-5.4.0-100-generic 5.4.0-100.113 amd64 Linux kernel extra modules for version 5.4.0 on 64 bit x86 SMP [17:55] ii linux-modules-extra-5.4.0-104-generic 5.4.0-104.118 amd64 Linux kernel extra modules for version 5.4.0 on 64 bit x86 SMP [17:59] oh, never mind, I now have had it fail on -100 as well, so it must be something else