Bug#1051492: is subject necessary

2023-09-12 Thread Alfred Agrell

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

2023-08-05 Thread Alfred Agrell
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)

2023-06-02 Thread Alfred Agrell
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

2015-07-14 Thread Alfred Agrell

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