diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1879955')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1879955 | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1879955 b/results/classifier/zero-shot/108/other/1879955 new file mode 100644 index 00000000..b3516190 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1879955 @@ -0,0 +1,77 @@ +permissions: 0.807 +semantic: 0.757 +graphic: 0.756 +other: 0.734 +PID: 0.722 +debug: 0.672 +socket: 0.658 +performance: 0.621 +vnc: 0.585 +device: 0.577 +network: 0.561 +KVM: 0.539 +files: 0.509 +boot: 0.434 + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? + +In target/i386/seg_helper.c:switch_tss_ra() we have the following code to load registers from a 16-bit TSS struct: + + /* 16 bit */ + new_cr3 = 0; + new_eip = cpu_lduw_kernel_ra(env, tss_base + 0x0e, retaddr); + new_eflags = cpu_lduw_kernel_ra(env, tss_base + 0x10, retaddr); + for (i = 0; i < 8; i++) { + new_regs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x12 + i * 2), + retaddr) | 0xffff0000; + } + for (i = 0; i < 4; i++) { + new_segs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x22 + i * 4), + retaddr); + } + new_ldt = cpu_lduw_kernel_ra(env, tss_base + 0x2a, retaddr); + +This doesn't match up with the structure described here: https://www.sandpile.org/x86/tss.htm -- which has only 2-byte slots for the segment registers. It also makes the 3rd segreg use the same offset as the LDTR, which is very suspicious. I suspect that this should use "(0x22 + i * 2)". + +The code later in the same function that stores the segment registers to the struct has the same bug. + +Found by code inspection; I don't have a test case to check this. As a non-x86-expert I'm just going to file a bug report in case somebody else feels like confirming the issue and sending a patch. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/382 + + |