Docker 20.10.16 has been released on May 12: https://github.com/moby/moby/releases/tag/v20.10.16 It includes a fix for a security issue in its bundled golang-x-sys. Mageia 8 is also affected.
CC: (none) => bruno, guillomovitchWhiteboard: (none) => MGA8TOO
Updated docker built by Bruno, but golang-x-sys hasn't been fixed yet. Speaking of which, our docker package BuildRequires some of our packaged golang modules, but not x-sys. I wonder if that could be fixed. Current Mageia 8 docker build: docker-fish-completion-20.10.16-1.mga8 docker-zsh-completion-20.10.16-1.mga8 docker-nano-20.10.16-1.mga8 docker-logrotate-20.10.16-1.mga8 docker-20.10.16-1.mga8 docker-devel-20.10.16-1.mga8 from docker-20.10.16-1.mga8.src.rpm
Status comment: (none) => docker has been updated, golang-x-sys needs to be fixed
(In reply to David Walser from comment #1) > Updated docker built by Bruno, but golang-x-sys hasn't been fixed yet. Our own golang-x-sys, right? CC'ing its registered maintainer, pterjan. Keeping this report assigned to Bugsquad, because with two packages involved I can't figure out whom to assign to. > > Speaking of which, our docker package BuildRequires some of our packaged > golang modules, but not x-sys. I wonder if that could be fixed. > > Current Mageia 8 docker build: > docker-fish-completion-20.10.16-1.mga8 > docker-zsh-completion-20.10.16-1.mga8 > docker-nano-20.10.16-1.mga8 > docker-logrotate-20.10.16-1.mga8 > docker-20.10.16-1.mga8 > docker-devel-20.10.16-1.mga8 > > from docker-20.10.16-1.mga8.src.rpm
CC: (none) => marja11, pterjan
I'll clone this report for golang-x-sys and keep this one for docker. Assigning QA, despite this line in David Walser's comment #1: > Speaking of which, our docker package BuildRequires some of our packaged > golang modules, but not x-sys. I wonder if that could be fixed. because Bruno already fixed his bundled golang-x-sys in docker a month ago, but our own golang-x-sys still isn't fixed. > Current Mageia 8 docker build: > docker-fish-completion-20.10.16-1.mga8 > docker-zsh-completion-20.10.16-1.mga8 > docker-nano-20.10.16-1.mga8 > docker-logrotate-20.10.16-1.mga8 > docker-20.10.16-1.mga8 > docker-devel-20.10.16-1.mga8 > > from docker-20.10.16-1.mga8.src.rpm
Assignee: bugsquad => qa-bugs
Blocks: (none) => 30646
Status comment: docker has been updated, golang-x-sys needs to be fixed => bug 30646 is for our own golang-x-sys nowBlocks: 30646 => (none)See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30646Summary: docker, golang-x-sys new security issue CVE-2022-29526 => docker, bundled golang-x-sys new security issue CVE-2022-29526
Where do you see that the bundled golang-x-sys is fixed?
Whiteboard: MGA8TOO => (none)Assignee: qa-bugs => brunoVersion: Cauldron => 8Status comment: bug 30646 is for our own golang-x-sys now => Need to see if golang-x-sys can be unbundled
(In reply to David Walser from comment #4) > Where do you see that the bundled golang-x-sys is fixed? If it isn't, then I misunderstood your comment 1 When you wrote: > Updated docker built by Bruno, but golang-x-sys hasn't been fixed yet. I understood that you meant that docker's golang-x-sys had been fixed, but our own golang-x-sys hadn't. I admit I wasn't sure at first, that why I asked (in comment 2) > Our own golang-x-sys, right? However, this morning I misread the docker changelog: bcornec <bcornec> 20.10.14-3.mga8: + Revision: 1825307 - Fix mga#30205 and CVE-2022-24769 - Fix mga#30205 and CVE-2022-24769 - Update libnetwork and requires_exclude golang-ipath - Update to upstream docker 20.10.9 - Update to upstream docker 20.10 for cgroupv2 support I saw "Fix mga#30422 and CVE-2022-29526" there :-(((( As soon as I make so many of such mistakes that I become more of a hassle than a help, then don't hesitate to tell me.
Ah, that was the wrong revision, this one says mga#30422 was fixed, but I still misread the CVE bcornec <bcornec> 20.10.16-1.mga8: + Revision: 1858109 - Update docker to upstream 20.10.16 to fix mga#30422 - Fix mga#30205 and CVE-2022-24769 - Fix mga#30205 and CVE-2022-24769 - Update libnetwork and requires_exclude golang-ipath - Update to upstream docker 20.10.9 - Update to upstream docker 20.10 for cgroupv2 support
And it really is fixed, from https://docs.docker.com/engine/release-notes/: 20.10.16 2022-05-12 This release of Docker Engine fixes a regression in the Docker CLI builds for macOS, fixes an issue with docker stats when using containerd 1.5 and up, and updates the Go runtime to include a fix for CVE-2022-29526.
this belongs to those release notes, too: Client Fixed a regression in binaries for macOS introduced in 20.10.15, which resulted in a panic docker/cli#43426. Update golang.org/x/sys dependency which contains a fix for CVE-2022-29526. Daemon Fixed an issue where docker stats was showing empty stats when running with containerd 1.5.0 or up moby/moby#43567. Updated the golang.org/x/sys build-time dependency which contains a fix for CVE-2022-29526. Packaging Updated Go runtime to 1.17.10, which contains a fix for CVE-2022-29526.
So the package is bundling it. I wanted to know if it can be unbundled. Would be nice to fix the other package too.
(In reply to David Walser from comment #9) > So the package is bundling it. I wanted to know if it can be unbundled. > Would be nice to fix the other package too. Here https://github.com/golang/go/issues/52313#issuecomment-1097210431 it says: "golang.org/x/sys/unix".Faccessat suffers from the same problem, but only on Linux kernels < 5.8. We have kernel-5.15.50-1.mga8 and kernel-5.18.12-1.mga9, so there's no need to test and push docker-20.10.16-1.mga8, right? If so, this report can be re-used for your request about the unbundling, in that case, please change the summary and obsolete the unrelated comments. If not, then it would be better to have a separate bug report for the unbundling
Ok, the CVE does appear to be a non-issue. Waiting for comment from Bruno about the bundling before closing.
(In reply to David Walser from comment #11) > Ok, the CVE does appear to be a non-issue. Waiting for comment from Bruno > about the bundling before closing. Oh, I was just filing bug 30647 about that. Well, this report is messy anyway, so closing this one
Resolution: (none) => INVALIDStatus: NEW => RESOLVED