FWIW I am still seeing a similar failure with 5.1.0rc3 (using a "Hello
World" like program in Ubuntu 20.04 x86_64 built statically):
$ mipsisa32r6el-linux-gnu-gcc --static -o h h.c
$ ./qemu-mipsn32el ./h
qemu: Unexpected FPU mode
big endian also seems to be affected
--
You received this bug not
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825002
Title:
"qemu: Unexpected FPU mode" since
0c1bbedc10e86ea9366b6af8c5520fafa32
A fix for this was committed as abcac736c1505254ec3 and will be in the
upcoming 4.1 release.
** Changed in: qemu
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/b
Fix posted on the list:
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04037.html
** Changed in: qemu
Status: Fix Committed => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bu
** Tags added: mips
** Tags added: linux-user
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825002
Title:
"qemu: Unexpected FPU mode" sinc
Thanks Peter. I was just reading up on the CVE process and I agree.
Obviously, it's dangerous to use uninitialized values, but that doesn't
necessarily make it a vulnerability.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
And thank you Thomas for the instructions!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825002
Title:
"qemu: Unexpected FPU mode" since
0c1bbedc10e86ea9366b6af8c5520fafa3266b2f
Status in QEMU:
This is certainly a bug, but it's not a a CVE, ie not a security bug.
The entire purpose of the linux-user mode is to run the guest ELF file
and let it perform whatever syscalls it likes -- it doesn't need to
exploit any kind of bug in the ELF loader to be able to control what the
process is doing.
Actually, this is a better patch. Let's sanitize struct image_info
interp_info.
** Patch added: "0001-1825002-fix-mips-Unexpected-FPU-mode.patch"
https://bugs.launchpad.net/qemu/+bug/1825002/+attachment/5256566/+files/0001-1825002-fix-mips-Unexpected-FPU-mode.patch
--
You received this bug
Please send patches to the mailing list for inclusion. QEMU maintainers
normally don't take patches from the bug tracker. See
https://wiki.qemu.org/Contribute/SubmitAPatch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
In load_elf_binary (linux-user/elfload.c b/linux-user/elfload.c:2644)
the entire interp_info struct should be inited, I would call this a CVE.
At a very minimum, init the fp_abi field so we don't use whatever
happened to be on the stack for the FPU mode should the ELF header not
specify otherwise.
** Attachment added: "This is my foreign /bin/bash, of note the first 1k
appears to be mis-handled"
https://bugs.launchpad.net/qemu/+bug/1825002/+attachment/5256368/+files/bash
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https
The check in target_cpu_copy_regs at linux-user/mips/cpu_loop.c:776 Is
reading an uninitialized value:
if ((info->fp_abi > MAX_FP_ABI && info->fp_abi != MIPS_ABI_FP_UNKNOWN)
|| (info->interp_fp_abi > MAX_FP_ABI &&
info->interp_fp_abi != MIPS_ABI_FP_UNKNOWN)) {
fpri
13 matches
Mail list logo
