diff options
author | wm4 <wm4@nowhere> | 2019-12-18 07:12:53 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-12-18 07:12:53 +0100 |
commit | 11d35b72a6fdd58f59ea7e593a4a5267f54b2e54 (patch) | |
tree | b38758cebddaa3cdfca83ec0446239110572b33d /osdep/macOS_swift_bridge.h | |
parent | 5f74ed58286a1339412554932f31844ec1b64280 (diff) | |
download | mpv-11d35b72a6fdd58f59ea7e593a4a5267f54b2e54.tar.bz2 mpv-11d35b72a6fdd58f59ea7e593a4a5267f54b2e54.tar.xz |
x11: fix X property out of bounds memory reads
The size overflow check was inverted: instead of allowing reading only
the first dst_size bytes of the property, it allowed copying past the
property buffer (as returned by xlib). xlib doesn't return the size of
the buffer in bytes, so it has to be computed and checked manually.
Wouldn't it be great if C allowed me to write the overflow check in a
readable way, so it doesn't trick me into writing dumb security bugs?
Relying on X security is even dumber than creating a X security bug,
though, so this was not a real problem. But I found that one specific
call tried to read more than what the property provided, so reduce that.
Also, len*ib obviously can't overflow, so there's an additional layer of
dumb to this whole thing.
While we're at dumb things, why the hell does xlib use "long" for 32 bit
types. It's a god damn pain.
Diffstat (limited to 'osdep/macOS_swift_bridge.h')
0 files changed, 0 insertions, 0 deletions