| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| All-Rend2-Stub-out-USE_BOX_CUBEMAP_PARALLAX-on-GLSL-1.30.patch | All: Rend2: Stub out USE_BOX_CUBEMAP_PARALLAX on GLSL < 1.30 Part of r_cubemapping patch by smcv |
MAN-AT-ARMS <M4N4T4RMS@gmail.com> | no | upstream, 1.51d, commit:4bbfab9fd0e3fa359571ad6a40e9790e2d013fa6 | 2019-03-17 | |
| build-Link-game-cgame-ui-modules-to-LIBS.patch | build: Link game, cgame, ui modules to $(LIBS) All three modules call mathematical functions like atan2(). On glibc systems, when compiled to native code with an ordinary C compiler (as opposed to bytecode from q3lcc), they get the definition of those functions from libm. Until now, they were not explicitly linked to libm, and instead relied on the fact that libm is linked into the main executable. However, doing it this way defeats glibc's symbol-versioning mechanisms, and can fail in some situations, in particular binaries built with -ffast-math on a pre-2.31 version of glibc (where atan2() resolves to __atan2_finite()), and used without recompilation on a post-2.31 version of glibc (where __atan2_finite() has become a deprecated hidden symbol that is only available as a versioned symbol). When building shared libraries and loadable modules, it's most robust to link them explicitly to their dependencies, as is done here. $(LIBS) also includes -ldl, which is unnecessary but harmless. |
Simon McVittie <smcv@debian.org> | yes | debian | 2020-07-24 | |
| debian/Disable-client-side-auto-download-by-default.patch | Disable client-side auto-download by default This feature is a security risk: it downloads executable bytecode. The interpreter is sandboxed, but a reasonably determined attacker can probably break out. Upstream rejected changes in this direction, but we want them in Debian anyway. |
Simon McVittie <smcv@debian.org> | no | 2015-03-23 | ||
| debian/File-access-methods-prevent-overwriting-DLLs-CVE-201.patch | File access methods: prevent overwriting DLLs (CVE-2011-3012) This is a known feature regression: it prevents mod DLLs from being unpacked from PK3 files (FS_CL_ExtractFromPakFile), making it considerably harder to install mods that contain arbitrary native code (such as those designed for retail RTCW). The opposite change, re-introducing the vulnerability, was made in commit <https://code.google.com/p/iortcw/source/detail?r=133> in order to fix FS_CL_ExtractFromPakFile. However, the feature that regresses here cannot be supported without re-introducing Quake III engine vulnerability CVE-2011-3012, and breaking some mods seems like a lesser evil than letting auto-downloads execute arbitrary and potentially malicious native code, either via a direct unpack of native code or via QVM code being allowed to open and write a file with the platform's DLL extension. FS_CL_ExtractFromPakFile relies on the vulnerable behaviour and is useless without it, so stub that out too. Add the same checks in SP file-copying code, for completeness (although in practice SP should never execute code not provided by either the retail RTCW binaries, iortcw or a deliberately-installed mod, because auto-downloading from a server is not applicable there). Upstream rejected this change, but we want it in Debian anyway. |
Simon McVittie <smcv@debian.org> | no | 2015-07-14 | ||
| debian/Remove-support-for-downloading-executable-updates.patch | Remove support for downloading executable updates This was off by default, which is good, because downloading and running unauthenticated code is a serious security issue. Upstream rejected changes in this direction, but we want them in Debian anyway. |
Simon McVittie <smcv@debian.org> | no | 2016-03-02 |