| SvenKieske | hi there, I was referred here from the "ubuntu-kernel" channel. I just wanted to ask if "linux-generic-hwe-20.04-edge" will get the update for "linux-generic-hwe-20.04-edge"? the metapackage seems not to be updated (yet)? | 09:20 |
|---|---|---|
| SvenKieske | sorry, c&p error, I meant if the hwe-edge kernel will get the update for https://ubuntu.com/security/CVE-2022-0847 | 09:21 |
| ubottu | A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the syste... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0847> | 09:21 |
| SvenKieske | ah, and if you don't mind, what does "Does not exist" even mean, on these CVE pages? I really couldn't figure that one out. All help would be highly appreciated, thanks in advance :) | 09:22 |
| amurray | Does Not Exist means that a given packaged is not published in a particular Ubuntu release - so as you can see this kernel is superceded by the linux-hwe kernel so you should use that one instead as linux-hwe-edge will not be updated for this or other CVEs | 09:29 |
| amurray | s/packaged/package/ | 09:29 |
| amurray | ah I see I was looking at the wrong package name - linux-generic-hwe-20.04-edge comes from the linux-meta-hwe-5.13 source package - and this has already been patched (see linux-hwe-5.13 on the CVE page) | 09:34 |
| amurray | tracking which kernel package is built from which source is a bit of a fine art | 09:34 |
| SvenKieske | yeah | 09:35 |
| SvenKieske | but I was just informed in #ubuntu-kernel, that "hwe-edge" in general receives no security updates at all, which is good to know, too.. | 09:35 |
| SvenKieske | I still find it weird, that the patch seems to be in git (but maybe I'm looking at the wrong git): https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?h=hwe-5.13&id=438da6e5c849ffe553fc15379471bf331346c3d2 | 09:36 |
| ubottu | Commit 438da6e in ~ubuntu-kernel/ubuntu/+source/linux/+git/focal "UBUNTU: Ubuntu-hwe-5.13-5.13.0-35.40~20.04.1 Ubuntu-hwe-5.13-5.13.0-35.40_20.04.1 hwe-5.13" | 09:36 |
| SvenKieske | nvm, that's "hwe", not "hwe-edge"...args..ubuntu has too many kernel variants.. (for my peculiar usecase). anyway, thanks! | 09:37 |
| JanC | maybe the -edge kernel shouldn't be in 'main' if it is not officially supported... | 09:39 |
| LocutusOfBorg | mdeslaur | 16:40 |
| LocutusOfBorg | The specific flaw exists in bionic and focal, but is not | 16:40 |
| LocutusOfBorg | currently exploitable due to lack of a flag that was introduced | 16:40 |
| LocutusOfBorg | in kernel 5.8. The flaw will be fixed as part of the next round | 16:40 |
| LocutusOfBorg | of bionic and focal kernel updates in case some other way of | 16:40 |
| LocutusOfBorg | exploiting it is discovered in the future. | 16:40 |
| LocutusOfBorg | mdeslaur, ^^ | 16:40 |
| LocutusOfBorg | speaking of CVE-2022-0847 | 16:41 |
| ubottu | A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the syste... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0847> | 16:41 |
| LocutusOfBorg | I checked on focal | 16:41 |
| LocutusOfBorg | and I exploited my own machine... | 16:41 |
| LocutusOfBorg | nevermind | 16:41 |
| LocutusOfBorg | Linux Unimatrix08-Focal 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux | 16:41 |
| LocutusOfBorg | :) | 16:41 |
| mdeslaur | yeah, that's the HWE kernel, and that one got an update | 17:30 |
| mdeslaur | I'll clarify in my note | 17:30 |
| LocutusOfBorg | actually was my fault | 17:49 |
| LocutusOfBorg | I forgot about hwe kernel | 17:49 |
| mdeslaur | someone else asked me the same thing, so clarifying the note is worth it | 17:55 |
| LocutusOfBorg | oh ok :D | 18:01 |
| ricotz | mdeslaur, hi, fyi https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2&id=c17b727d4ec5bc20678122303ca118ea8f7c5e3d | 20:51 |
| ubottu | Commit c17b727 in ~libreoffice/ubuntu/+source/libreoffice "Restrict parallelism to 3 on amd64" | 20:51 |
| ricotz | afaict lgw01 builders were capable, but lcy02 are not :( | 20:52 |
| ricotz | mdeslaur, also https://launchpad.net/ubuntu/+source/libreoffice/1:7.2.6-0ubuntu0.21.10.1 | 20:53 |
| mdeslaur | ricotz: oh! that's why that was failing...thanks for the hint! | 20:54 |
| mdeslaur | ricotz: I saw the new version in -proposed, so I'll rebuild mine based on it | 20:54 |
| ricotz | mdeslaur, is there really another rebuild for impish needed? | 20:55 |
| mdeslaur | ricotz: it needs to go into the -security pocket so it gets installed with unattended-upgrades | 20:55 |
| mdeslaur | ricotz: to go in the -security pocket, it needs to be built with -updates disabled | 20:56 |
| ricotz | mdeslaur, so using the currently running build is not an option? | 20:56 |
| ricotz | I see | 20:56 |
| mdeslaur | ricotz: the -security vs -updates split is annoying | 20:56 |
| ricotz | mdeslaur, better just pick the build fix for 7.2.5 then? | 20:56 |
| ricotz | still why the rebuild needed? | 20:57 |
| ricotz | expat isn't statically linked | 20:57 |
| mdeslaur | because if it builds against -updates, it may get dependencies that exist only in -updates | 20:58 |
| mdeslaur | which would render it uninstallable when only -security is enabled | 20:58 |
| ricotz | ok, please use 7.2.5 then | 20:59 |
| mdeslaur | why 7.2.5 instead of 7.2.6? | 21:00 |
| ricotz | to respect the SRU process? | 21:00 |
| mdeslaur | I'll wait a week for 7.2.6 to get released | 21:00 |
| mdeslaur | I'm in no hurry for the security updates, it can wait | 21:00 |
| ricotz | alright | 21:02 |
| ricotz | mdeslaur, please feel free to ping in such occasions | 21:03 |
| mdeslaur | ricotz: if might be simpler to have the SRUs be built without -updates enabled in the future, so they can simply be copied to -security | 21:04 |
| mdeslaur | we can discuss it next time there's an update to do, either an SRU or a security update | 21:04 |
| ricotz | ack, as long there is nothing vital in -updates/-proposed | 21:06 |
| ricotz | e.g. glib/gtk3/qt5 updates can be runtime deps | 21:07 |
| mdeslaur | yeah, if there is, I have to rebuild them in -security | 21:08 |
| mdeslaur | happens once in a while | 21:08 |
| ricotz | this won't help if the tests or autopkgtests are failing | 21:09 |
| mdeslaur | what do you mean? | 21:09 |
| ricotz | I mean if a library dependency is fixing runtime issues which are affecting the results of tests/autopkgtests you would need those newer versions | 21:11 |
| mdeslaur | yes, and in which case I would rebuild then as no-change rebuilds in the -security pocket | 21:11 |
| ricotz | but the package would fail to build | 21:12 |
| mdeslaur | if libreoffice needs the newer glib from -updates to pass the autopkgtests, I need to first build glib in -security, release it, then I can build libreoffice in -security | 21:13 |
| mdeslaur | what would fail to build? | 21:13 |
| ricotz | alright | 21:13 |
| ricotz | "make check" is fatal on amd64/arm64 | 21:13 |
| ricotz | I don't remember seeing this in the past, but I usually build/test with -updates/-proposed | 21:15 |
| mdeslaur | yeah, as I've said, I really hate the -security/-updates split, but around 30% of our customers run with -updates disabled, and for the rest, unattended-upgrades won't pull stuff from -updates | 21:16 |
| mdeslaur | so the only way for users to get security updates is to have stuff in the -security pocket, built with -updates disabled | 21:17 |
| mdeslaur | and when that doesn't happen, we get pinged | 21:18 |
| ricotz | I understand, just indicating possible ill effects | 21:18 |
| * mdeslaur nods | 21:19 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!