Bug#1051492: is subject necessary
And that commit does indeed change window handling: https://salsa.debian.org/wine-team/wine/-/commit/e055001f272c3a3d7a0b28865f1de9fda13c2f10#fb90e219a3e9d2931384a3375b23cedfd6b428fb Manually applying that piece to upstream Wine reproduces the issue (or at least reproduces issue #1043052 - I don't have Syberia, so I can't test that one). The problem is that escape.drawable is often assigned 0 in the loop, and if that happens, it undoes the X11DRV_get_whole_window( top ) and does something inappropriate. Since escape.drawable is already set to 0 at the top of that function, I have no idea what warning that patch is trying to remove, and I believe the best solution would be simply reverting that part.
Bug#1043052: wine: d3d9 doesn't work on WS_CHILD windows
Package: wine Version: 8.0~repack-4 Severity: normal X-Debbugs-Cc: blub...@gmail.com Dear Maintainer, please compile and run the following program (x86_64-w64-mingw32-gcc test.c -ld3d9 && wine a.exe): #include #include #include #include HWND wnd_parent; HWND wnd; int f; LRESULT myWindowProcA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { printf("%d %u %d\n", hWnd==wnd, Msg, f++); if (Msg == WM_CLOSE) exit(0); return DefWindowProcA(hWnd, Msg, wParam, lParam); } int main() { WNDCLASSEXA wcex = { sizeof(WNDCLASSEX), CS_DBLCLKS, myWindowProcA, 0L, 0L, NULL, NULL, NULL, NULL, NULL, "windowclass", NULL }; RegisterClassEx(); WNDCLASSEXA wcex2 = { sizeof(WNDCLASSEX), 0, myWindowProcA, 0L, 0L, NULL, NULL, NULL, NULL, NULL, "windowclass_child", NULL }; RegisterClassEx(); uint32_t wstyle = WS_CAPTION|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_MINIMIZEBOX; uint32_t wstyleex = WS_EX_ACCEPTFILES|WS_EX_WINDOWEDGE|WS_EX_CONTROLPARENT; wnd_parent = CreateWindowExA(wstyleex, "windowclass", "parent", wstyle, 0, 0, 640, 480, NULL, NULL, NULL, NULL ); ShowWindow(wnd_parent, SW_SHOWDEFAULT); UpdateWindow(wnd_parent); wnd = CreateWindowExA(0, "windowclass_child", "child", WS_CHILD, 0, 0, 320, 240, wnd_parent, NULL, NULL, NULL ); ShowWindow(wnd, SW_SHOWDEFAULT); UpdateWindow(wnd); IDirect3D9* d3d = Direct3DCreate9(D3D_SDK_VERSION); DWORD BehaviorFlags = D3DCREATE_SOFTWARE_VERTEXPROCESSING | D3DCREATE_MULTITHREADED; D3DPRESENT_PARAMETERS d3dpp = {}; D3DDISPLAYMODE dm; IDirect3D9_GetAdapterDisplayMode(d3d, D3DADAPTER_DEFAULT, ); d3dpp.Windowed = TRUE; d3dpp.SwapEffect = D3DSWAPEFFECT_COPY; d3dpp.BackBufferFormat = dm.Format; d3dpp.BackBufferHeight = 640; d3dpp.BackBufferWidth = 480; d3dpp.hDeviceWindow = wnd_parent; IDirect3DDevice9* d3ddev; IDirect3D9_CreateDevice(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, BehaviorFlags, , ); IDirect3D9* d3d2 = Direct3DCreate9(D3D_SDK_VERSION); d3dpp.hDeviceWindow = wnd; IDirect3DDevice9* d3ddev2; IDirect3D9_CreateDevice(d3d2, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, BehaviorFlags, , ); for (int frame=0;frame<600;frame++) { IDirect3DDevice9_Clear(d3ddev, 0,NULL,D3DCLEAR_TARGET,D3DCOLOR_RGBA(255,0,frame*4,0),1.0f,0); IDirect3DDevice9_Present(d3ddev, NULL, NULL, NULL, NULL ); IDirect3DDevice9_Clear(d3ddev2, 0,NULL,D3DCLEAR_TARGET,D3DCOLOR_RGBA(0,255,frame*4,0),1.0f,0); IDirect3DDevice9_Present(d3ddev2, NULL, NULL, NULL, NULL ); MSG msg; while( (PeekMessage( , NULL, 0, 0, PM_REMOVE )) != 0) { TranslateMessage(); DispatchMessage(); } } } Expected behavior: Should show an animated green-teal rectangle, and an animated red-magenta L shape. Actual behavior: Shows a black rectangle, and the expected red-magenta L shape. Dragging another window over the black rectangle leaves the pixels unchanged, duplicating the window border a bunch of times. I have verified that the expected result shows up - if I build Wine 8.0 from source - if I build latest Wine git from source (somewhere around version 8.13) - on Ubuntu 22.04's Wine package (6.0.3~repack-1) - on Arch's Wine package (8.13-1) - on Windows 7 - on Windows 10 therefore I believe that this bug is Debian-specific somehow. -- Package-specific info: /usr/bin/wine points to /usr/bin/wine-stable. -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wine depends on: ii wine32 8.0~repack-4 ii wine64 8.0~repack-4 wine recommends no packages. Versions of packages wine suggests: ii dosbox0.74-3-4+b1 pn exe-thumbnailer | kio-extras pn playonlinux pn q4wine pn winbind pn wine-binfmt pn winetricks Versions of packages libwine depends on: ii libasound2 1.2.8-1+b1 ii libc62.36-9+deb12u1 ii libcapi20-3 1:3.27-3+b1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libglib2.0-0
Bug#1037041: linux-image-6.1.0-9-amd64: Spurious failures from mmap(MAP_32BIT)
Package: src:linux Version: 6.1.27-1 Severity: normal Tags: upstream X-Debbugs-Cc: blub...@gmail.com Dear Maintainer, Please run this program 20 times: #include #include #include int main() { for (int i=0;i<1000;i++) { void* p = mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0); if (p != MAP_FAILED) printf("."); else if (errno == ENOMEM) printf("E"); else printf("(%d)", errno); } puts(""); } Expected behavior: It should print 1000 dots. If 1000 is increased to 10, it should print some dots, then some Es. It should never print a dot after an E; if it's out of address space, it shouldn't suddenly find new address space if the operation is retried. Actual behavior: Kernel version 6.1.0-7-amd64: On 13 of 20 runs, it prints 1000 dots. On some, it prints one to three randomly scattered Es (never an E before at least 155 dots), and the rest is dots. Kernel version 6.1.0-9-amd64: On 8 of 20 runs, it prints 1000 dots. On some, it prints one to four randomly scattered Es, first one after only 16 dots. On some runs, there are long sequences of Es with a few dots interspersed; worst case, only 383 of 1000 mmap()s succeed. Additional information: Running this on a few other computers, and asking some friends to run it, returns - Ubuntu 22.04 (kernel 5.19.0-43-generic): 1000 dots, every time. - Debian 11 (kernel 5.10.0-21-amd64): 1000 dots, every time. - Arch (kernel 6.3.3-arch1-1): Same pattern as 6.1.0-9-amd64. - Arch (kernel 6.3.4-arch1-1): 1000 dots, every time. - Fedora 38 (kernel 6.2.15-300.fc38.x86_64): Same pattern as 6.1.0-9-amd64. so I suspect it depends, at least partially, on kernel configuration. The more practical impact (and the context where I first encountered this bug) is that the game Creeper World 3 frequently (~85% of the time) segfaults at launch (after 437th line of strace output) under kernel 6.1.0-9-amd64, while it reliably launches under 6.1.0-7-amd64. (Unfortunately, the game is closed source and commercial, so I'm not sure if you want a link in your bug tracker. The binary is freely available on the developer's website; it asks for a license key, but the crashing part is far before that.) I'm happy to provide strace logs, kernel config, and whatever else; just tell me what you need. -- Package-specific info: ** Version: Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=UUID=3f03a19e-1f7e-43c8-a4e9-6297f87ce127 ro quiet ** Not tainted ** Kernel log: [2.147324] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1f.3/sound/card0/input14 [2.147886] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1f.3/sound/card0/input15 [2.148024] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input16 [2.148081] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input17 [2.148161] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input18 [2.160594] Bluetooth: Core ver 2.22 [2.160606] NET: Registered PF_BLUETOOTH protocol family [2.160606] Bluetooth: HCI device and connection manager initialized [2.160609] Bluetooth: HCI socket layer initialized [2.160610] Bluetooth: L2CAP socket layer initialized [2.160614] Bluetooth: SCO socket layer initialized [2.168164] usbcore: registered new interface driver btusb [2.168428] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [2.258383] pcieport :00:1c.5: AER: Multiple Corrected error received: :00:1c.5 [2.258411] pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [2.258413] pcieport :00:1c.5: device [8086:43bd] error status/mask=0001/2000 [2.258416] pcieport :00:1c.5:[ 0] RxErr (First) [2.258423] pcieport :00:1c.5: AER: Multiple Corrected error received: :00:1c.5 [2.258436] pcieport :00:1c.5: AER: can't find device of ID00e5 [2.291946] pcieport :00:1c.5: AER: Multiple Corrected error received: :00:1c.5 [2.291977] pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [2.291980] pcieport :00:1c.5: device [8086:43bd] error status/mask=0081/2000 [2.291985] pcieport :00:1c.5:[ 0] RxErr (First) [2.291989] pcieport :00:1c.5:[ 7] BadDLLP [2.394348] ath10k_pci :03:00.0: firmware: failed to load ath10k/pre-cal-pci-:03:00.0.bin (-2) [2.394397] firmware_class: See https://wiki.debian.org/Firmware
Bug#792420: zsnes: emulator escape vulnerability
On Tue, 14 Jul 2015 18:57:02 +0200 Etienne Millon m...@emillon.org wrote: * Paul Wise p...@debian.org [150714 18:20]: According to this Youtube video and forum post, there are at least 3 vulnerabilities in zsnes that allow ROMs to escape the zsnes emulator and execute arbitrary code on the host running zsnes. The known issues will be fixed in 1.52 but there may be more issues. This may or may not be related to the cppcheck warnings from bug #610313. Thanks for the report. While neither the exploit code nor a fix is out, I believe that the best course of action is indeed to write a patch for #610313. It may also be possible that due to hardening patches, this bug is not exploitable in Debian. -- Etienne Millon I am the one who created that PoC, so I know all relevant facts about these vulns. #610313 is irrelevant, these vulns are all in assembly. Whatever hardening you're thinking of is also insufficient, there isn't even any ASLR in this program. The three aforementioned vulns (along with something in the C code, not sure if it's exploitable) are patched upstream: http://svn.zsnes.com/comp.php?repname=zsnespath=%2Fcompare[]=%2F@5307compare[]=%2F@5308 http://svn.zsnes.com/comp.php?repname=zsnespath=%2Fcompare[]=%2F@5310compare[]=%2F@5311 There is also a fourth vuln that they didn't patch yet: http://svn.zsnes.com/filedetails.php?repname=zsnespath=%2Ftrunk%2Fsrc%2Fcpu%2Fspc700.asmrev=4492sc=1 Op4E should use SPCRAM, not [spcRamDP]. This leads to an exploitable buffer overflow. Vuln 5: A crafted savestate can set wramrwadr to something impossible, leading to yet another exploitable overflow. And yes, it is very likely that more exploits exist. ZSNES is an enormous pile of decades-old code, written more for performance than security and correctness. I'm surprised they've remained hidden for so long. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org