On Thu, 31 Aug 2017 12:11:00 +0000 astian <[email protected]> wrote: > Control: found -1 1:2.8+dfsg-7 > Control: tags -1 + patch fixed-upstream > > Hi, > > After staring at GDB for ungodly spans of time I managed to track down this > bug, ipso facto discovering that it was already fixed upstream quite some time > ago... > > I think you took upstream commit 04bf2526ce87f21b32c9acba1c5518708c243ad0 > (exec: use qemu_ram_ptr_length to access guest ram) from v2.10.0-rc0. That > patch introduced the bug. It was fixed about a month ago in v2.10.0-rc1; see: > > - https://patchwork.ozlabs.org/patch/794015/ > - > https://git.qemu.org/gitweb.cgi?p=qemu.git;a=commit;f=exec.c;h=f5aa69bdc3418773f26747ca282c291519626ece > > I include an easy backport of that patch (very minor tweaks needed for it to > apply to v2.8.1) that you can drop at the end of debian/patches/series. I > tested this in a trial amd64 build and it seems to have solved the problem > for me. > > Suggestion: merge these threads: > > tags 871648 - moreinfo unreproducible > tags 871648 + confirmed > merge 871648 871702 872257
Now that's interesting. The thing is that I've never seen this email. Now I come across it while trying to understand what's going on here. The only xen-related patch, as I thought, which I used, was this one: xen-disk-don-t-leak-stack-data-via-response-ring-CVE-2017-10911.patch, but it looks like it does not affect the problem. However, as you noted above, exec-add-lock-parameter-to-qemu_ram_ptr_length - looks like it is where the problem is. After reading upstream discussion I've even more confidence here. Thank you very much for pointing out to the solution. I'll try to fix this in stretch as soon as possible. THanks! /mjt
