| dikonoor | amurray: This is on https://ubuntu.com/security/CVE-2022-2327. I am trying to understand which are the kernel versions that are impacted. There is a note in this that says - 'initial investigation indicates that this likely only affects | 11:26 |
|---|---|---|
| dikonoor | 5.10 and earlier, but not as far back as 5.4. But everything about | 11:26 |
| dikonoor | this issue is unclear.' | 11:26 |
| ubottu | io_uring use work_flags to determine which identity need to grab from the calling process to make sure it is consistent with the calling process when executing IORING_OP. Some operations are missing some types, which can lead to incorrect reference counts which can then lead to a double free. We recommend upgrading the kernel past commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2327> | 11:26 |
| dikonoor | Are there any more updates on this? Or information on what is the impacted version | 11:26 |
| dikonoor | We had discussed about this and two other CVEs few days back > https://irclogs.ubuntu.com/2022/08/17/%23ubuntu-security.html and you had mentioned that the fixes for these CVEs might be available in the 29th Aug update. I see that there's a new version of the kernel namely 5.4.0-125 out but the CVEs don't have updates. So I am not able to figure out if the fixes for these have gone in or not. | 11:28 |
| dikonoor | The 3 CVEs are https://ubuntu.com/security/CVE-2022-1012, https://ubuntu.com/security/CVE-2022-2327 and https://ubuntu.com/security/CVE-2022-36946. I am on Ubuntu 20.04 , kernel 5.4.0 and I am trying to figure out which are the impacted ones and which of the fixes are available. | 11:29 |
| ubottu | A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size. This flaw may allow an attacker to information leak and may cause a denial of service problem. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1012> | 11:29 |
| ubottu | io_uring use work_flags to determine which identity need to grab from the calling process to make sure it is consistent with the calling process when executing IORING_OP. Some operations are missing some types, which can lead to incorrect reference counts which can then lead to a double free. We recommend upgrading the kernel past commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2327> | 11:29 |
| ubottu | nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36946> | 11:29 |
| amurray | dikonoor: so you can see for 2 of those they are marked as 'needed' for focal (20.04) so you should assume they are affected and not yet patched - it looks like 2022-2327 is still waiting to be triaged by the kernel team (basically where they go looking to see if they have the affected commit in the various ubuntu kernel git trees) | 11:37 |
| dikonoor | amurray: So I guess this means none of the 3 are part of the update that happened yesterday? | 11:40 |
| dikonoor | Especially the first 2. Third one as you mentioned is not yet triaged | 11:40 |
| amurray | dikonoor: it looks like 2022-36946 is in https://launchpad.net/ubuntu/+source/linux/5.4.0-126.142 which is currently in focal-proposed so will be in the next stable kernel release | 11:43 |
| dikonoor | amurray: Thanks. I believe that would be after 3 weeks. So mostly around 19th Sept I assume | 11:44 |
| amurray | dikonoor: yep https://kernel.ubuntu.com/ | 12:03 |
| dikonoor | amurray: Thanks! | 12:05 |
| luna__ | Fedora will discuss what they are gonna do about the Security panel in around 20-30 minutes | 13:27 |
| luna__ | decided to not hide it and helped give feedback to make it better | 14:24 |
| === kees_ is now known as kees | ||
| hggdh | folks, are you aware of bug 1988119? I understand laney took it off at the moment; but I am not sure what is the actual problem (apart from unattended-updates not restarting systemd-resolved) | 19:05 |
| ubottu | Bug 1988119 in systemd (Ubuntu) "Update to systemd 237-3ubuntu10.54 broke dns" [Undecided, Confirmed] https://launchpad.net/bugs/1988119 | 19:05 |
| sarnold | aware of, yes; root-caused, no | 19:06 |
| hggdh | thanks. We neded up with a sev 1 at Azure :-) | 19:11 |
| sarnold | an exciting time :( | 19:15 |
| question2 | how do i make my live usb stick read only and with only one partition? | 20:59 |
| question2 | i do sudo sha256sum /dev/sdb | 21:00 |
| question2 | and i expect it to be the same | 21:00 |
| sarnold | question2: that sounds tailor-made for https://manpages.ubuntu.com/manpages/jammy/en/man8/veritysetup.8.html | 21:03 |
| question2 | what is that? | 21:04 |
| question2 | xubuntu 18.04.5 is still like that but xubuntu 22 is not anymore | 21:05 |
| sarnold | dm-verity provides for read-only hash-verified filesystems | 21:05 |
| question2 | but my iso is written with dd | 21:05 |
| question2 | ! | 21:05 |
| question2 | does dm-verity change my iso? | 21:07 |
| sarnold | question2: wait, what problem are you trying to solve? | 21:07 |
| question2 | i want it to be tamper evident | 21:08 |
| sarnold | what is "it"? | 21:08 |
| question2 | write the iso with dd to the usb stick | 21:08 |
| question2 | hash the entire usb stick and expect always the same value | 21:08 |
| question2 | xubuntu 18.04.5 is still like that but xubuntu 22 is not anymore | 21:09 |
| Eickmeyer | question2: if it makes you feel any better, the image verifies itself when you go to run it. | 21:12 |
| question2 | ... | 21:14 |
| question2 | how do i google that? | 21:14 |
| sarnold | question2: ah, so, if I've understood you correctly -- you've written an arbitrary ISO to a memory stick. you read the memory stick back and get a different sha256sum. you're curious how you can get the same value back every single time? | 21:16 |
| sarnold | question2: I believe the hardware doesn't guarantee this sort of repeatability, and I don't know why. I'd expect that you get the same sha256sum for any specific ISO that you write to the stick, every time you compute it, but I don't think it necessarily matches the data you wrote to the stick | 21:17 |
| question2 | it works | 21:20 |
| question2 | i know | 21:20 |
| question2 | if you make dd if=xubuntu.18.04.5 of=/dev/sdX | 21:21 |
| question2 | and you boot once from that stick | 21:22 |
| question2 | if you then make sudo sha256sum /dev/sdX | 21:22 |
| question2 | at anytime | 21:22 |
| question2 | it will be the same! | 21:23 |
| question2 | but if you do : dd if=xubuntu.22 or mint of=/dev/sdX | 21:25 |
| question2 | it does not work anymore, because there is a writeable partition | 21:25 |
| question2 | anyway thanks | 21:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!