| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Apply-version-string-substitutions-from-the-tarball.patch | Apply version string substitutions from the tarball | Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 102_fix-pearl-min-dimensions.diff | pearl: Require width or height to be at least 6 for Tricky Josh Triplett reported: > If I ask pearl to generate a 5x5 tricky puzzle, it runs forever. I find that 5x6 or 6x5 works, so set the minimum accordingly. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2018-08-10 | |
| fix-ftbfs-with-gcc-6.patch | Fix FTBFS with gcc 6 gcc 6 warns about statements that are indented as if they were meant to be part of a preceding conditional block. In this case I don't think that was intended, so shift it left. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2016-06-30 | |
| 0004-Makefile.doc-Remove-CHM-files-in-clean-rule.patch | Makefile.doc: Remove CHM files in clean rule | Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 206_translate-docs.diff | Support translated docs using po4a | Ben Hutchings <ben@decadent.org.uk> | no | debian | 2018-08-10 | |
| 0006-Add-German-translation-of-documentation.patch | Add German translation of documentation This was done by Helge Kreutzmann. |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 201_make-more-docs.diff | Add rules and script to build manual pages and HTML Halibut already supports these formats but since the documentation is all combined we need to do a bit more work to extract the right information for each game's manual page. |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 202_online-help.diff | Add HTML-based online help This works along the same lines as the Windows implementation, though we have to try a bit harder to find a help browser. |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 207_slant-shade-filled.diff | slant: Shade filled squares | Ben Hutchings <ben@decadent.org.uk> | no | debian | 2018-08-10 | |
| 303_show-debian-version-number.diff | Show Debian package version number Include Debian version number in any version display to make it obvious that the binaries are built from modified source. |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 0011-mkfiles.pl-Change-first-line-to-usr-bin-perl.patch | mkfiles.pl: Change first line to #!/usr/bin/perl Debian policy 10.4 says it must be this and not "#!/usr/bin/env perl". [git-debrebase: split mixed commit: upstream part] |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-08-10 | ||
| 0012-unruly-Fix-memory-leak-in-dup_game.patch | unruly: Fix memory leak in dup_game() The common structure is ref-counted and dup_game() bumps the reference count rather than copying it. However, blank_state() always allocates a new instance. Add a parameter to control whether blank_state() allocates it. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-08-17 | ||
| 0013-bridges-Fix-off-by-one-in-WITHIN.patch | bridges: Fix off-by-one in WITHIN() WITHIN() used to treat the min and max as inclusive bounds but was changed to treat the max as exclusive, apparently accidentally. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-08-17 | ||
| 0014-pattern-Fix-build-failure-with-fortify-and-gcc-9-on-.patch | pattern: Fix build failure with fortify and gcc 9 on some architectures Building with gcc 9 and _FORTIFY_SOURCE=2 (the default on Debian) fails for some architectures, with error messages such as: In file included from /usr/include/string.h:495, from ./pattern.c:7: In function memset, inlined from do_row at ./pattern.c:456:9: /usr/include/mips64el-linux-gnuabi64/bits/string_fortified.h:71:10: error: __builtin_memset specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The length argument is len, implicitly converted from int to size_t. Apparently the compiler thinks len might be negative and convert to an enormous positive value. Assert that it is not. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2020-01-31 | ||
| 0015-Update-German-translation-thanks-to-Helge-Kreutzmann.patch | Update German translation, thanks to Helge Kreutzmann [git-debrebase split: mixed commit: upstream part] |
Ben Hutchings <ben@decadent.org.uk> | no | 2020-02-02 | ||
| 0007-Mines-add-validation-for-negative-mine-count.patch | [PATCH 007/389] Mines: add validation for negative mine count. If this gets through validation, it causes an infinite loop after gameplay begins. |
Simon Tatham <anakin@pobox.com> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d71ac73d8a4397c35b21ec08388a1c6f94691b64 | 2020-03-17 | |
| 0023-Galaxies-fix-assertion-failure-when-adding-out-of-bo.patch | [PATCH 023/389] Galaxies: fix assertion failure when adding out-of-bounds association. Adding an association with an out-of-bounds square (i.e. by pressing Return with a dot selected, and then moving the cursor so the `opposite' arrow was off the screen) would cause space_opposite_dot() to return NULL, in turn causing ok_to_add_assoc_with_opposite_internal() to return false, failing the assertion. This assertion appears to have been introduced in 68363231. |
Franklin Wei <franklin@rockbox.org> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=84cb4c6701e027090ff3fd955ce08065e20121b2 | 2020-07-05 | |
| 0028-Filling-fix-assertion-failure-in-3x1-game-generation.patch | [PATCH 028/389] Filling: fix assertion failure in 3x1 game generation. This would come up on the game id "3x1#12345", for example. The failing assertion was (s->board[f] != EMPTY) in expand(), called in turn from learn_expand_or_one(). It looks as if the problem was that the #define SENTINEL was set too small. It was intended to be a value that can't coincide with the true size of any region - and it was set to precisely the area of the whole board. But on a 3x1 grid, that _can_ coincide with the size of a region! So a board entry was set to a real region size, and then mistaken for SENTINEL by another part of the code. Easy fix: set SENTINEL to be sz+1. Now it really can't coincide with a region area. |
Simon Tatham <anakin@pobox.com> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=1fcb61cffe538c11a11fc2ec94d6470a61df019e | 2021-03-14 | |
| 0081-Map-add-missing-sresize-in-new_game_desc.patch | [PATCH 081/389] Map: add missing sresize in new_game_desc(). Every time we append to the string 'ret', we check first that there's enough space, and realloc it larger if it's getting close to full. Except that I missed one case at the join between the two parts of the encoding. (Spotted because apparently on someone's build platform this led to a compiler warning that 'ret' might be null. I think _that's_ not a serious worry, but the missing resize was definitely unintentional.) |
Simon Tatham <anakin@pobox.com> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=3e006158451a7ff8f130cbcb7dd80f165a58396e | 2021-12-11 | |
| 0114-Add-more-validation-to-midend-deserialisation-routin.patch | [PATCH 114/389] Add more validation to midend deserialisation routine These are all pretty obvious and enforce constraints that would otherwise be enforced by segfault. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=02e5e93046d1ee2ce7acde629a6562db9b36fa5d | 2022-10-16 | |
| 0115-Correct-and-enable-the-range-check-on-statepos-when-.patch | [PATCH 115/389] Correct and enable the range check on statepos when loading statepos == 0 shouldn't ever occur in a save file because it indicates an uninitialised midend. OTOH statepos == nstates is normal. Also added an equivalent assertion when saving because Simon and I spent some time discussing whether it could happen. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=1bab1d1d2ab472bb8fc7cddfce1d3c37e63a2ed5 | 2022-10-16 | |
| 0121-Add-an-assertion-to-check-the-format-of-encoded-para.patch | [PATCH 121/389] Add an assertion to check the format of encoded parameters Whenever the midend calls encode_params, it also checks that the result is a printable ASCII string that doesn't contain '#' or ':'. Parameter strings are embedded in save files, so they have to fit within ASCII. They can't contain '#' or ':' because those delimit the parameter section of a game ID. Nothing explicitly says they can't contain control characters, but those would be a particularly egregious violation of the recommendation that parameter strings be easy to type into a shell. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e29d8a3ecad734967cdcf2d4ce222ab27e9c524b | 2022-10-15 | |
| 0122-Add-assertions-that-game-descriptions-consist-only-o.patch | [PATCH 122/389] Add assertions that game descriptions consist only of printable ASCII. That they are ASCII is implied by their inclusion in save files. Nothing requires an absence of control characters, but it seems polite to make them slightly readable. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9f2eef876275a451b015c22961130b2e507ddd49 | 2022-10-15 | |
| 0123-Hex-encode-non-ASCII-random-seeds-in-save-files.patch | [PATCH 123/389] Hex-encode non-ASCII random seeds in save files The developer documentation claims that save files are long ASCII strings. This is mostly true, but there's nothing stopping a user from entering non-ASCII characters as random seeds. The ASCII property of save files is useful, so encode seeds in hex before writing them unless they consist only of printable ASCII characters. Hex-encoded seeds are written under a new key, HEXSEED, to distinguish them from unencoded seeds. This means that old versions of the code won't be able to load encoded seeds, but that's not a great loss: seeds aren't generally portable between versions anyway. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=304796f9f184a783d0af21e445c690ed69de048b | 2022-10-17 | |
| 0124-Assert-that-everything-written-to-a-save-file-is-pri.patch | [PATCH 124/389] Assert that everything written to a save file is printable ASCII Apart from the newlines of course. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=7f4d038258d2bd585a0dce87177bf429d168ffb5 | 2022-10-17 | |
| 0129-Build-fix-take-declarations-out-of-for-loops.patch | [PATCH 129/389] Build fix: take declarations out of for loops. The NestedVM build is still unhappy with this C99ism, unfortunately. |
Simon Tatham <anakin@pobox.com> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=373dadacc06210197e3d68c55a6d611126915120 | 2022-10-21 | |
| 0246-galaxies-Use-the-same-code-for-handling-all-dropped-.patch | [PATCH 246/389] galaxies: Use the same code for handling all dropped arrows The keyboard code was prone to adding null items to the undo history, and was also unreadable. Rather than fix it, I've replaced it with a jump to the mouse drop handling, lightly enhanced to reject drops on things that aren't tiles. |
Ben Harris <bjh21@bjh21.me.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=0b036c9e79578cec5425aaca1b1af13a4ae0d937 | 2022-12-07 | |
| 0263-magnets-Area-constraints-fix-message.patch | [PATCH 263/389] magnets: Area constraints; fix message. (The restriction on 2x2 puzzles is because the board layer-out doesn't use neutral pieces on such small boards, and the only soluble 2x2 boards have neutral pieces. I haven't investigated the Tricky size limit, but it seems entirely reasonable that all the smaller boards are too easy. --bjh21) (cherry picked from Android port, commit 133794977a13767e0c1596be6a5b26f2cf2d1fd1) |
Chris Boyle <chris@boyle.name> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=69e63a810e0bd6f85a46d8490c6e366237e061ef | 2016-12-20 | |
| 0266-lightup-Ban-2x2-with-either-4-way-type.patch | [PATCH 266/389] lightup: Ban 2x2 with either 4-way type (2x2 with four-way symmetry must be either all-black (trivial) or all-white (ambiguous). --bjh21) (cherry picked from Android port, commit 27ae898e118b0a31a98d393bf56aa138845123e6) |
Chris Boyle <chris@boyle.name> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=cbf2ede64ad91346e6399603ff7b8df432be5a06 | 2016-12-20 | |
| 0267-Remove-_-introduced-from-Android-port.patch | [PATCH 267/389] Remove _() introduced from Android port. Introduced in cbf2ede64a. It's used there for marking up text for i18n in a gettext stylee, but is not available here. |
Jacob Nevins <jacobn@chiark.greenend.org.uk> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=0d43753ff2e02f54dd35e6872be3dafa14d2ea7d | 2022-12-16 | |
| 0269-Solo-Set-max-difficulty-for-small-jigsaw-puzzles.patch | [PATCH 269/389] Solo: Set max difficulty for small jigsaw puzzles (cherry picked from Android port, commit 5c9a7b64a06d07f97a41622c4b91d81f3419a51b) |
Michael Quevillon <mquevill@nd.edu> | no | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=11c1447eac7698f01c2a00764c2b1a900a9d6a90 | 2022-04-03 | |
| 0285-Add-a-macro-of-an-upper-bound-on-the-formatted-lengt.patch | [PATCH 285/389] Add a macro of an upper bound on the formatted length of an integer There are lots of places where Puzzles formats integers into fixed-length buffers using sprintf() with a "%d" format. This isn't very safe, since C doesn't guarantee any particular maximum size for an "int". However, the restrictions on representations of integers means we can infer an upper bound using sizeof(), CHAR_BIT, and an approximation to the binary log of 10. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d246077e78bb1aeafe8829927db23f281cd03c72 | 2023-01-02 |
| 0299-Guess-Don-t-allow-any-moves-once-the-game-is-solved.patch | [PATCH 299/389] Guess: Don't allow any moves once the game is solved If the game is solved (either by a win or a loss), interpret_move() can never return a move, but execute_move() should also reject any moves in case we're loading a corrupt or malicious save file. Otherwise a save file with more guesses than the maximum allowed can cause a buffer overrun. This save file demonstrates the problem when loaded into a build of Puzzles with AddressSanitizer: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Guess PARAMS :9:c6p4g1Bm CPARAMS :9:c6p4g1Bm DESC :8:b5f3faed NSTATES :1:3 STATEPOS:1:3 MOVE :8:G1,1,2,2 MOVE :8:G4,3,1,1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c84af670b52f09e9e47587584c0559c508d4a37d | 2023-01-07 |
| 0300-Guess-validate-peg-colours-in-decode_ui.patch | [PATCH 300/389] Guess: validate peg colours in decode_ui() Peg colours in the current guess must be within the range of colours for the current game, just as they must be for completed moves. Otherwise is_markable() can cause a buffer overrun. Since there's no way for decode_ui() to report an error, it just ignores the bad peg colours. I've also added an assertion to catch this problem in is_markable(). The following save file demonstrates the problem when loaded in a build with AddressSanitizer: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Guess PARAMS :9:c6p4g10Bm CPARAMS :9:c6p4g10Bm DESC :8:2de917c0 UI :7:7,7,7,7 NSTATES :1:1 STATEPOS:1:1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5279fd24b2f4a51e760bfde873fe1d29547220a6 | 2023-01-07 |
| 0302-Netslide-Reject-moves-wider-than-the-grid.patch | [PATCH 302/389] Netslide: Reject moves wider than the grid Also add a corresponding assertion to the underlying move primitive. Without this limit, long moves cause a buffer overrun. To demonstrate the problem, build Netslide with AddressSanitizer and load this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :8:Netslide PARAMS :3:4x4 CPARAMS :3:4x4 DESC :16:49b59aca247714b4 NSTATES :1:2 STATEPOS:1:2 MOVE :5:R3,51 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=1aded127eb3fb7194a1752d96bfba95a5b7fa4dc | 2023-01-07 |
| 0303-Sixteen-limit-length-of-moves.patch | [PATCH 303/389] Sixteen: limit length of moves The code that actually executes the moves can only cope with moves of at most the width (or height as appropriate) of the grid. Reject any longer move, and for symmetry also negative moves of the same magnitude. Without this, the tile-moving code tends to access off the start of the tile array. To demonstrate this, build Sixteen with AddressSanitizer and load this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :7:Sixteen PARAMS :3:4x4 CPARAMS :3:4x4 DESC :38:2,16,3,10,13,8,7,4,9,14,12,11,15,1,5,6 NSTATES :1:2 STATEPOS:1:2 MOVE :4:C1,9 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=023ce7554c19dcf6f4432407b9eedb850acc7289 | 2023-01-07 |
| 0304-Undead-check-for-valid-commands-in-execute_move.patch | [PATCH 304/389] Undead: check for valid commands in execute_move() Previously, Undead's execute_move would go into a spin when it encountered an unexpected command character in a move string. Now it rejects the move instead. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=a02c55b0492453ea7ca4e4ae63cb90ba4c93a3a5 | 2023-01-07 |
| 0305-Undead-fix-buffer-overrun-in-M-command.patch | [PATCH 305/389] Undead: fix buffer overrun in "M" command The guessable squares are numbered up to num_total, not "wh". The latter includes mirror squares that aren't included in the various arrays describing the game state. To reproduce the problem, build Undead with AddressSanitizer and press "M". |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=952ef8ca565d803da1134466358bd85683a489a3 | 2023-01-07 |
| 0306-Correct-RANGECHECK-macro-in-Black-Box.patch | [PATCH 306/389] Correct RANGECHECK macro in Black Box Lasers are numbered from 0 to nlasers-1 inclusive, so the upper limit should be "<", not "<=". |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=4845f3e913a02417fe7a8d84c6407d40807ec0ec | 2023-01-08 |
| 0307-Range-check-normal-moves-in-Undead.patch | [PATCH 307/389] Range-check normal moves in Undead Normal moves shouldn't be allowed to write outside the board. This buffer overrun can be demonstrated by building Undead with AddressSanitizer and loading this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :6:Undead PARAMS :5:4x4dn CPARAMS :5:4x4dn DESC :48:5,0,5,cRRaLRcLRc,0,2,1,3,1,0,0,3,4,3,2,3,4,2,1,1 NSTATES :1:2 STATEPOS:1:2 MOVE :3:Z10 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=942d883d9bf86f4240dc7ec22b726d64f6db9af2 | 2023-01-08 |
| 0308-Range-check-record-lengths-when-deserialising-games.patch | [PATCH 308/389] Range-check record lengths when deserialising games "1999999999999999999999999999999999999999999999999999" as a record length should lead to an error, not a buffer overrun. (fun fact that was less obvious to me than it should have been: very large powers of ten are multiples of large powers of two, so that number is -1 mod 2^32) This bug can be demonstrated by building any puzzle with AddressSanitizer and then loading this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1999999999999999999999999999999999999999999999999999:1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e5717d1ba2184eb6e38b4e2a9d29dc4704aeef30 | 2023-01-08 |
| 0309-Don-t-load-too-many-states-just-because-there-s-no-S.patch | [PATCH 309/389] Don't load too many states just because there's no STATEPOS If we start seeing state records in a save file (MOVE, SOLVE, or RESTART), we should already have seen STATEPOS, so emit an error if not. This avoids the situation where we overrun the end of the state array because we're continuing loading states in the hope a STATEPOS will come along. I've also added an assertion that we're not overrunning the state array for added paranoia. An earlier version of this fix just removed the test for data.statepos at the head of the loop, but that's wrong for a file that only has the initial state. This bug can be demonstrated by building Bridges with AddressSanitizer and loading this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :7:Bridges PARAMS :13:7x7i30e10m2d0 CPARAMS :13:7x7i30e10m2d0 DESC :24:a4b4a1g1a2a8a4a4m2b2b3e3 NSTATES :1:2 MOVE :10:L1,0,4,0,1 MOVE :10:L1,0,4,0,2 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b3d4a4197954c21ac78b68c58dff8f84fe743ea2 | 2023-01-07 |
| 0310-Palisade-forbid-moves-that-remove-grid-edges.patch | [PATCH 310/389] Palisade: forbid moves that remove grid edges Without this check, a corrupt save file can include a move that removes an edge of the grid, and then is_solved() walks off the edge of the grid causing a buffer over- or under-run. To demonstrate the bug, load this save file in a build with AddressSanitizer: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :8:Palisade PARAMS :5:5x5n5 CPARAMS :5:5x5n5 DESC :0: NSTATES :1:2 STATEPOS:1:2 MOVE :6:F0,0,1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=21193eaf9308ace41004a19180ff382ec6e8754b | 2023-01-12 |
| 0311-Last-ditch-maximum-size-limit-for-Bridges.patch | [PATCH 311/389] Last-ditch maximum size limit for Bridges This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=97484b098f33266f6c747c292c708281cb15a286 | 2023-01-10 |
| 0312-Last-ditch-grid-size-limit-for-Dominosa.patch | [PATCH 312/389] Last-ditch grid-size limit for Dominosa At least prevent integer overflow when constructing the grid. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b3f3345764b0808a7a97b9c3a2a1888fd62383a0 | 2023-01-11 |
| 0313-Last-ditch-grid-size-limit-for-Galaxies.patch | [PATCH 313/389] Last-ditch grid-size limit for Galaxies At least prevent integer overflow when constructing the grid. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d422dd6009f3e48e13d5f7f162813537902e125c | 2023-01-10 |
| 0314-Last-ditch-grid-size-limit-for-Fifteen.patch | [PATCH 314/389] Last-ditch grid-size limit for Fifteen At least prevent integer overflow when constructing the grid. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=522588f699b3c910c5a47f8b8185e69250665313 | 2023-01-10 |
| 0315-Last-ditch-maximum-size-limit-for-Flip.patch | [PATCH 315/389] Last-ditch maximum size limit for Flip This makes sure that width * height <= INT_MAX, which it rather needs to be. Also in Flip's case that the square of the area still fits in an int. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=26d0633f87ccdbaf7035e2e14d9dfbfd7f379527 | 2023-01-10 |
| 0316-Last-ditch-grid-size-limit-for-Flood.patch | [PATCH 316/389] Last-ditch grid-size limit for Flood At least prevent integer overflow when constructing the grid. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=da220a77d1793edd14144fd96584b7f461f06dfb | 2023-01-10 |
| 0317-Insist-that-Flood-grids-must-have-non-zero-size.patch | [PATCH 317/389] Insist that Flood grids must have non-zero size | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d60192531e3ee6b492151f6aa8edd481ebddcdf7 | 2023-01-11 |
| 0318-Last-ditch-grid-size-limit-for-Inertia.patch | [PATCH 318/389] Last-ditch grid-size limit for Inertia At least prevent integer overflow when constructing the grid. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=98724b90936c46e457234a0189bb09242fc727d1 | 2023-01-11 |
| 0319-Last-ditch-maximum-size-limit-for-Light-Up.patch | [PATCH 319/389] Last-ditch maximum size limit for Light Up This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=fcda12f4b73e69841fd8957b8e33930c584093e5 | 2023-01-10 |
| 0320-Limit-maximum-grid-size-in-Loopy.patch | [PATCH 320/389] Limit maximum grid size in Loopy Every grid shape has its own limit, so this involved adding a new interface between loopy.c and grid.c. The limits are based on ensuring that the co-ordinate system of the grid doesn't overflow INT_MAX and neither do the lengths of the face and dot arrays. Though now I come to look at it I think the actual limits of grid.c are much lower. Hmm. [benh: Backported to 20191231: Drop the change to compassdodecagonal grid which isn't implemented here.] |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d71bba1a17d6b228e7dd8b437dccbd3f6bc4698c | 2023-01-11 |
| 0321-Last-ditch-maximum-size-limit-for-Magnets.patch | [PATCH 321/389] Last-ditch maximum size limit for Magnets This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=261a9568faeeb7acc6e56bd67147917c5109ac8a | 2023-01-11 |
| 0322-Last-ditch-maximum-size-limit-for-Map.patch | [PATCH 322/389] Last-ditch maximum size limit for Map This makes sure that width * height <= INT_MAX, which it rather needs to be. Also a similar check in decode_params when defaulting the number of regions. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ed75535fc24217c51f900d42385309c8c8b36cc3 | 2023-01-10 |
| 0323-Last-ditch-maximum-size-limit-for-Mines.patch | [PATCH 323/389] Last-ditch maximum size limit for Mines This makes sure that width * height <= INT_MAX, which it rather needs to be. Also a similar check in decode_params when defaulting the number of mines. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5cc9bfb811854b66c4a570e8100b8a1aad037f0e | 2023-01-10 |
| 0324-Also-check-for-tiny-grids-in-Mines.patch | [PATCH 324/389] Also check for tiny grids in Mines A zero-size grid isn't acceptable even if someone has generated it for us. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9e2e0692ed087dbe0d5f4abbddf3aebd6a11b30e | 2023-01-10 |
| 0326-Last-ditch-maximum-size-limit-for-Net.patch | [PATCH 326/389] Last-ditch maximum size limit for Net This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=051357bb24c0f05c291d6f9e6b460839847923b4 | 2023-01-10 |
| 0327-Last-ditch-maximum-size-limit-for-Netslide.patch | [PATCH 327/389] Last-ditch maximum size limit for Netslide This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=40ec3aaf09824face187218f899494aef429a9c6 | 2023-01-10 |
| 0328-Integer-overflow-protection-in-Pattern.patch | [PATCH 328/389] Integer overflow protection in Pattern Both for grid sizes and for clue values. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=dd00e9c532abc7517bd7ca72c8e4db91bb2da821 | 2023-01-11 |
| 0329-Last-ditch-maximum-size-limit-for-Palisade.patch | [PATCH 329/389] Last-ditch maximum size limit for Palisade This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=91c0fac1dc98be2ecc074d83368df74f9f755641 | 2023-01-10 |
| 0330-Last-ditch-maximum-size-limit-for-Pearl.patch | [PATCH 330/389] Last-ditch maximum size limit for Pearl This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=8a3fb82e230c5cf18b82f54687c2a56f53875a38 | 2023-01-10 |
| 0331-Last-ditch-maximum-size-limit-for-Pegs.patch | [PATCH 331/389] Last-ditch maximum size limit for Pegs This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=6e40605f1ed4ecce400faae5b41c03995e7f862c | 2023-01-10 |
| 0332-Also-limit-Pegs-to-at-least-1x1-even-when-not-doing-.patch | [PATCH 332/389] Also limit Pegs to at least 1x1 even when not doing full validation | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b090c82df1527dcf348c96765f10ab5736c68c29 | 2023-01-10 |
| 0333-Last-ditch-maximum-size-limit-for-Same-Game.patch | [PATCH 333/389] Last-ditch maximum size limit for Same Game This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d5ec2758ee3b7a8934475a1122813ad2312dc850 | 2023-01-10 |
| 0334-Last-ditch-maximum-size-limit-for-Signpost.patch | [PATCH 334/389] Last-ditch maximum size limit for Signpost This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5c36e1536a05abf514b09476813cf71bc9dc1e31 | 2023-01-10 |
| 0335-Last-ditch-maximum-size-limit-for-Sixteen.patch | [PATCH 335/389] Last-ditch maximum size limit for Sixteen This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=91d96fa0bc133c8d967f3c4b01804e7773de8504 | 2023-01-10 |
| 0336-Limit-size-of-puzzle-in-Tents-to-avoid-integer-overf.patch | [PATCH 336/389] Limit size of puzzle in Tents to avoid integer overflow | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=07999443c24414602cf046fefc84d1d17b5afd69 | 2023-01-12 |
| 0337-Last-ditch-maximum-size-limit-for-Tracks.patch | [PATCH 337/389] Last-ditch maximum size limit for Tracks This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c53e0d386793840ad84b8bbcb4760cfb2b6897d4 | 2023-01-10 |
| 0338-Last-ditch-maximum-size-limit-for-Twiddle.patch | [PATCH 338/389] Last-ditch maximum size limit for Twiddle This makes sure that width * height <= INT_MAX, which it rather needs to be. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=51dcf4add6e046568557cee2fa01975f14716889 | 2023-01-10 |
| 0339-Adjust-Undead-upper-grid-size-limit-to-avoid-overflo.patch | [PATCH 339/389] Adjust Undead upper grid-size limit to avoid overflow | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=85ccdf2f75e3ea55d5e92d9790e50394e1bec089 | 2023-01-10 |
| 0340-Last-ditch-point-count-limit-for-Untangle.patch | [PATCH 340/389] Last-ditch point-count limit for Untangle Anything over INT_MAX/3 will cause an integer overflow, so put the limit there for now. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d5b8a20def7634d4df79800fe54d8e34c6353974 | 2023-01-10 |
| 0341-Black-Box-correct-order-of-validation-checks-for-F-c.patch | [PATCH 341/389] Black Box: correct order of validation checks for "F" commands It doesn't do much good to range-check an argument after using it as an array index. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c2eedeedfe3c48f3f013fb1308f61d7ef94e8b2c | 2023-01-08 |
| 0342-Palisade-don-t-leak-memory-on-a-bad-move.patch | [PATCH 342/389] Palisade: don't leak memory on a bad move Invalid moves can turn up in corrupted save files, and puzzles shouldn't leak memory when failing to load a corrupted save file. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=38cf1955e5861f67d385ede006c5b5d1701aca8d | 2023-01-12 |
| 0343-Don-t-allow-negative-clues-in-Pattern.patch | [PATCH 343/389] Don't allow negative clues in Pattern | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e5d106eb279c12d2454802421e723873e4bae6c2 | 2023-01-12 |
| 0344-When-loading-don-t-decode_ui-unless-we-have-a-UI.patch | [PATCH 344/389] When loading, don't decode_ui unless we have a UI If the save file doesn't have a UI line, it's not sensible to try to decode it. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=68f9fae973e2ffb6c0b9ed1e0761d3a0768455ad | 2023-01-07 |
| 0346-Palisade-remove-assertion-from-decode_ui.patch | [PATCH 346/389] Palisade: remove assertion from decode_ui() Other games tolerate receiving an encoded game_ui even if they can never generate one. This is sensible, since it means that if a new version starts saving UI state, old versions can load save files generated by those newer versions. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=0dbbd52935b8b17b3b3ab3d9ae6271cde891f70b | 2023-01-07 |
| 0347-Same-Game-reject-moves-with-unexpected-characters-in.patch | [PATCH 347/389] Same Game: reject moves with unexpected characters in Previously if a move string starting with "M" contained anything else other than a digit or a comma, execute_move() would spin trying to parse it. Now it returns NULL. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=8c5279cf75e41f1ae75b2daf0d06c883a5ae0bca | 2023-01-07 |
| 0349-Filling-validate-length-of-auto-solve-move-strings.patch | [PATCH 349/389] Filling: validate length of auto-solve move strings Without this, execute_move() can end up reading off the end of the move string, which isn't very friendly. Also remove the comment saying that the move string doesn't have to be null-terminated, because now it does. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=8a06ff26fc6abd77a4b4a08b839943f588d92dcf | 2023-01-08 |
| 0350-Tighten-Bridges-validate_desc.patch | [PATCH 350/389] Tighten Bridges' validate_desc() It allowed V, W, X, Y, H, I, J, and K to appear in game descriptions even though new_game() didn't ascribe any meaning to those letters and would fail an assertion if they ever occurred. As far as I can tell, those letters have never done anything, so I've just removed the checks for them from validate_desc(). |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ba944f9f95238d0b820e63d9b6c2d83efc09b8a2 | 2023-01-08 |
| 0351-Untangle-forbid-descriptions-that-connect-a-node-to-.patch | [PATCH 351/389] Untangle: forbid descriptions that connect a node to itself These cause an assertion failure in new_game(), so they should be rejected by validate_desc(). |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=d3290195da55beae04d1bb86f811b6f8dd6b0663 | 2023-01-08 |
| 0352-Mines-No-moving-once-you-re-dead.patch | [PATCH 352/389] Mines: No moving once you're dead! If a Mines save file contains a move after the player has already died, this can lead to an assertion failure once there are more mines that covered squares. Better to just reject any move after the player's died. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5bd02f982a878312065b4d81d05a90bc41a98c6c | 2023-01-08 |
| 0353-Towers-reject-descriptions-with-odd-characters-at-th.patch | [PATCH 353/389] Towers: reject descriptions with odd characters at the end Towers' new_game() causes an assertion failure on game description strings that contain spurious characters after a valid description, so validate_desc() should also refuse such a description. The problem could be demonstrated by editing the game description in the "Specific" dialogue box to add a '!' at the end, which caused "new_game: Assertion `!*p' failed.". |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=15974d06bbaad287382c6eeb8deb7c6f3a627278 | 2023-01-09 |
| 0354-Tracks-make-sure-moves-are-valid-in-execute_move.patch | [PATCH 354/389] Tracks: make sure moves are valid in execute_move() Tracks allowed moves in execute_move() that shouldn't have been allowed, like changing the state of the edges of the board. This moves couldn't be generated by interpret_move(), but could be loaded from a save file. Now execute_move() uses the same ui_can_flip_*() functions as interpret_move() to decide whether a particular move is allowed. This should prevent some assertion failures when loading corrupted save files. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5782e29db43034574763b1d10c48486c3e95f0d2 | 2023-01-09 |
| 0360-Tracks-let-solve-make-illegal-moves.patch | [PATCH 360/389] Tracks: let solve make illegal moves Not only does it set the outer edges to NOTRACK, but it may also overwrite any mistakes the user has previously made elsewhere. Otherwise, the entire solve is rejected ("Solve unavailable" error on Android) if the user has made a single mistake, which is inconsistent with the other games. This may be giving a free pass to corrupted moves that occur after a solve, so this may still want tightening up in some way, but it's still limited to squares within the grid, so I agree with Ben's assessment that this is likely not to be exploitable. Fixes #584 (cherry picked from Android port, commit 33bd14fb6f7cd760e7218fffd90f3a266b1f4123) |
Chris Boyle <chris@boyle.name> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b5e02b0b9c1b35b0b907bf6d63e62b9fafd9cb7e | 2023-01-18 |
| 0361-Tracks-tighten-up-the-illegal-solve-submoves-fix.patch | [PATCH 361/389] Tracks: tighten up the 'illegal solve submoves' fix. Chris mentioned in the commit message that there was a risk that illegal moves might be permitted when playing on after a solve. So I've changed the condition so that it depends only on whether the move _currently being executed_ is a solve, rather than whether there was a solve action anywhere in the undo history. (Also, wrapped overlong lines while I was here.) |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b4aaa11943fb72b09fe173bc97bd9313ff94738c | 2023-01-19 |
| 0362-Allow-repeated-solve-operations-in-Guess.patch | [PATCH 362/389] Allow repeated "solve" operations in Guess Since using the "solve" option doesn't consume a guess, it's safe to allow it to occur multiple times. Without this, selecting "solve" a second time causes an assertion failure because solve() returns a move string that's rejected by execute_move(). Possible solve() could instead refuse to solve an already-solved puzzle, but that seems needlessly pedantic. [fixes c84af670b52f09e9e47587584c0559c508d4a37d] |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=27c97c0ffdda0b91fecf155f3bc29b32ed806bb2 | 2023-01-19 |
| 0001-Black-Box-reject-negative-ball-counts-in-game_params.patch | [PATCH 001/159] Black Box: reject negative ball counts in game_params. You can inject one via a game desc string such as "10x10M5m-1", and it's clearly silly. _Zero_ balls, on the other hand, are a perfectly fine number: there's nothing incoherent about a BB puzzle in which the possible numbers of balls vary from (say) 0 to 5 inclusive, so that part of the challenge is to work out as efficiently as possible whether there are even any balls at all. (We only need to check minballs, because once we know minballs >= 0, the subsequent check ensures that maxballs >= minballs, and hence, by transitivity, maxballs >= 0 too.) |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5cac6a09c4db2b7e05c3e8dfd8920e2cdd1b8b03 | 2023-01-22 |
| 0002-Add-validate_params-bounds-checks-in-a-few-more-game.patch | [PATCH 002/159] Add validate_params bounds checks in a few more games. Ben tells me that his recent work in this area was entirely driven by managed to prove that the lack of them allowed something buggy to happen. It seemed worth doing an eyeball-review pass to complement that strategy, so in this commit I've gone through and added a few more checks that restrict the area of the grid to be less than INT_MAX. Notable in this commit: cube.c had to do something complicated because in the triangular-grid modes the area isn't calculated as easily as w*h, and Range's existing check that w+h-1 < SCHAR_MAX is sufficient to rule out w*h being overlarge _but_ should be done before w*h is ever computed. |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b907e278751b740da7b9dc00c0cbdb93e7498919 | 2023-01-22 |
| 0006-Don-t-allow-Bridges-games-with-2-islands.patch | [PATCH 006/159] Don't allow Bridges games with < 2 islands Technically, a game with no islands is always solved, but it causes a null-pointer dereference at startup because there's nowhere to put the cursor. Games with one island are always insoluble because the island must have at least one bridge and there's nowhere for it to go. So the minimum playable game has two islands. To demonstrate the segfault, try loading this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :7:Bridges PARAMS :1:3 CPARAMS :1:3 DESC :1:i NSTATES :1:1 STATEPOS:1:1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=a98ac4bb428ab5c1ff665aa1def6cc14d02a4e19 | 2023-01-28 |
| 0007-Forbid-moves-that-fill-with-the-current-colour-in-Fl.patch | [PATCH 007/159] Forbid moves that fill with the current colour in Flood This avoids an assertion failure, "oldcolour != newcolour" in fill(), by catching it it execute_move(). As far as I know this couldn't be triggered from the UI, but it could be demonstrated with this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Flood PARAMS :1:3 CPARAMS :1:3 DESC :12:231353400,11 NSTATES :1:3 STATEPOS:1:3 MOVE :2:M3 MOVE :2:M3 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=eb1ae3f3d041f9ff0c11b04613a695be11bda706 | 2023-01-28 |
| 0008-Cleanly-reject-ill-formed-solve-moves-in-Flood.patch | [PATCH 008/159] Cleanly reject ill-formed solve moves in Flood A solve move containing characters other than digits and commas would cause an assertion failure, "*p == ','", in execute_move(). Such a move can't as far as I know be generated in play, but can be read from a corrupt save file. Here's a sample of such a save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Flood PARAMS :7:3x3c6m5 CPARAMS :7:3x3c6m5 DESC :12:403011503,10 NSTATES :1:2 STATEPOS:1:2 SOLVE :2:SA |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e4112b322e299a461ddc46daee741c73733e186d | 2023-01-28 |
| 0009-Don-t-segfault-on-premature-solve-moves-in-Mines.patch | [PATCH 009/159] Don't segfault on premature solve moves in Mines If a save file contained a solve move as the first move, Mines would dereference a null pointer trying to look up the (at that point undetermined) mine locations. Now execute_move() politely returns NULL instead. This save file demonstrates the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Mines PARAMS :5:3x3n0 CPARAMS :5:3x3n0 DESC :127:r0,u,7a142789cabddc3fc4dcb7d2baa4a4937b33c9613ea870ac098e217981ad339930af585557d62048ea745d05b01475d9699596b394cc0adeebf0440a02 UI :2:D0 TIME :1:0 NSTATES :1:2 STATEPOS:1:2 SOLVE :1:S |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=28671e76b736aeb860b1f725898c45fe70ae6212 | 2023-01-28 |
| 0010-Limit-number-of-mines-in-Mines-game-description.patch | [PATCH 010/159] Limit number of mines in Mines game description Without this, it's possible to specify a description that has more mines than there are places on the board to place them, which eventually leads to a division by zero. This can be demonstrated by entering a game description of "3:r8,u," and then clicking anywhere on the board. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=75e8a1a9cabe7567f6019b1226783b61ba1ac42f | 2023-01-28 |
| 0011-Validate-the-number-of-pegs-and-holes-in-a-Pegs-game.patch | [PATCH 011/159] Validate the number of pegs and holes in a Pegs game ID Without this, "1:O" causes an assertion violation, '!"new_ui found nowhere for cursor"'. We may as well require two pegs and one hole, since that's the minimum for a game in which there are any moves to make. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=4359f59dd22770a94e29b2ddd54b533ad1713550 | 2023-01-28 |
| 0017-Mines-forbid-moves-that-flag-or-unflag-an-exposed-sq.patch | [PATCH 017/159] Mines: forbid moves that flag or unflag an exposed square interpret_move() couldn't generate them, but execute_move() also needs to forbid them to defend against corrupt save files. I don't think this actually caused any crashes, but it did cause unexpected "1" squares not adjacent to mines. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=17364455186ae61e015d0f0de3f09423f78d0727 | 2023-02-01 |
| 0018-Mines-Don-t-check-if-the-player-has-won-if-they-ve-a.patch | [PATCH 018/159] Mines: Don't check if the player has won if they've already lost It can't happen in normal play, but if a save file had a "C" (clear around) move that set off a mine, Mines could end up hitting an assertion failure, "ncovered >= nmines". This was because it would check if the player had won by counting covered squares and mines, and of course an uncovered mine is no longer a covered square but is still a mine. Since winning after you're dead isn't possible (at least in Mines), we now skip the check entirely if the player has already died. This save file demonstrates the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :5:Mines PARAMS :1:7 CPARAMS :1:7 DESC :22:r31,u,0000C000d0000020 NSTATES :1:2 STATEPOS:1:1 MOVE :4:C6,2 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=2a9be2b89df3e6a07a1d90a06f8ac00a92d789e5 | 2023-02-01 |
| 0019-Avoid-invalid-moves-when-solving-Tracks.patch | [PATCH 019/159] Avoid invalid moves when solving Tracks The solver, when it decided that an edge or square should be both TRACK and NOTRACK, would correctly decide that the puzzle was insoluble, but would also mark the edge with both flags in its working copy. This could then lead to assertion violations if that working copy of the board was used for something else, for instance if it was fed back into the solver. This couldn't happen in normal play, since failed solutions just cause the solve command to fail, but the diagnostic "H" command could trigger it from a save file, causing an assertion failure: "state->sflags[y*state->p.w + x] & S_CLUE". Now when the solver runs into this situation, it marks the puzzle as insoluble but doesn't set the invalid flag, so the board remains valid and future solve operations are safe. This save file is the one that demonstrated the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :12:Train Tracks PARAMS :5:6x6t0 CPARAMS :5:6x6t0 DESC :31:b0t9l,,S0,00,0,0,4,0,0,S0,0,0,0 NSTATES :1:8 STATEPOS:1:2 MOVE :1:H MOVE :1:H MOVE :1:H MOVE :1:H MOVE :1:H MOVE :1:H MOVE :1:H |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=875f0af21fbced5cbf6cf63b86fe3dc51682c863 | 2023-02-01 |
| 0020-Fix-move-validation-in-Netslide.patch | [PATCH 020/159] Fix move validation in Netslide The maximum length of a column move in Netslide is the height of the puzzle, and the maximum length of a row move is the width, not the other way around. Moves of absolute length more than 1 can't be generated by interpret_move(), but they can come from save files. On non-square grids, the incorrect check led to assertion failures: "0 <= tx && tx < w" and "0 <= ty && ty < h". This save file demonstrates the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :8:Netslide PARAMS :3:4x9 CPARAMS :3:4x9 DESC :39:0000000000000h0h0000000000000000000000v NSTATES :1:2 STATEPOS:1:2 MOVE :4:R0,5 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ed0e4c304bed990948541fc0cf87309d75653806 | 2023-02-01 |
| 0021-Tighten-validation-of-Tents-game-descriptions.patch | [PATCH 021/159] Tighten validation of Tents game descriptions Specifically, TENT and NONTENT markers ('!' and '-') cannot appear as the first or last character of a description, because that would attempt to place them on squares outside the grid. This was caught by assertions in new_game(), as can be demonstrated by feeding these descriptions to older versions of Tents: "4:-p,0,0,0,0,0,0,0,0" ("new_game: Assertion `i >= 0 && i <= w*h' failed.") and 4:p-,0,0,0,0,0,0,0,0 ("new_game: Assertion `*desc == ','' failed."). |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ed682bd5c608156d12ebaa2d84c4ce2e2877c10a | 2023-02-02 |
| 0022-Dominosa-require-the-two-halves-of-a-domino-to-be-ad.patch | [PATCH 022/159] Dominosa: require the two halves of a domino to be adjacent Also that a line indicating no domino be between adjacent squares. Without this, execute_move would allow you to place dominos and edges between any pair ot squares, and then generate assertion failures ("execute_move: Assertion `d2 - w >= 0' failed." and "execute_move: Assertion `d1 - w >= 0' failed.") when a domino was placed over an invalid edge. This example save file demonstrates the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :8:Dominosa PARAMS :1:6 CPARAMS :1:6 DESC :56:55521461210004364611033535444421636022603153156422620503 NSTATES :1:3 STATEPOS:1:3 MOVE :4:E0,2 MOVE :4:D0,2 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=294a3ac6e703c2820ceb7b28a1a5492b61e9a531 | 2023-02-02 |
| 0023-Forbid-lines-off-the-grid-in-Pearl.patch | [PATCH 023/159] Forbid lines off the grid in Pearl While they couldn't be generated in normal play, execute_move() would permit lines and marks across the edge of the grid that would then generate assertion failures ("dsf_update_completion: Assertion `INGRID(state, bx, by)' failed."). I've added a check to execute_move() that after updating a square, the square doesn't have any lines or marks that leave the grid. This save file demonstrated the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSZON :1:1 GAME :5:Pearl PARAMS :5:5x6dt CPARAMS :5:5x6dt DESC :6:eeeeee NSTATES :1:2 STATEPOS:1:1 MOVE :6:F1,4,2 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=15f4fa851a5781cf77984a6046405ffa758e7b33 | 2023-02-02 |
| 0024-Tolerate-incorrect-solutions-in-Inertia.patch | [PATCH 024/159] Tolerate incorrect solutions in Inertia The "solve" operation in Inertia generates a proposed solution as a move string. But if such a move string is loaded from a save file it might not actually describe a solution. If that happens then it's possible to reach the end of the "solution" without winning, and doing so should probably cause a recalculation of the solution rather than an assertion failure ("execute_move: Assertion `ret->solnpos < ret->soln->len' failed."). I am a little concerned by the way that normal solve operations end up encoded in the save file, but the re-solvings caused by going off course don't, but I haven't got a good answer to that. Here's a save file that demonstrates the assertion failure: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :7:Inertia PARAMS :3:8x8 CPARAMS :3:8x8 DESC :64:sbgwsmswwgggwggmmbwgwbssbwbsbwbbwsSmwbbsbbmggbmssgmgwbmmwmbmmwsw NSTATES :2:3 STATEPOS:1:1 MOVE 000:2:S0 MOVE 000:2:00 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=843d4ca17def11671809786f2a5aebd75f230dd9 | 2023-02-03 |
| 0025-Palisade-replace-dfs_dsf-with-a-simple-iteration.patch | [PATCH 025/159] Palisade: replace dfs_dsf() with a simple iteration. The whole purpose of a dsf is that you can traverse the edges of your graph in any order you feel like. So if you want to build the connected components of a graph you can just loop over all the edges once. There's no need to run a depth-first search. In fact there were an amazing number of things wrong with this 10-line function: - As Ben points out in commit 21193eaf9308ace, it didn't bother with bounds checking when searching the grid, instead relying on the never-removed grid boundary to stop the search - which was fragile in the face of other bugs. - The recursion uses linear stack, which is much worse than linear heap, since stacks are often much more limited. (And the dsf _also_ used linear heap.) - The recursion was completely unnecessary. - The function used internal knowledge about dsf.c in order to define the value UNVISITED to match what would happen to work. - The name 'dfs_dsf' is totally confusing and almost impossible to type! |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=517b14e666b0b71fc0bcd5da1b22cdc90d3434c9 | 2023-02-03 |
| 0026-latin_solver_alloc-handle-clashing-numbers-in-input-.patch | [PATCH 026/159] latin_solver_alloc: handle clashing numbers in input grid. In the setup phase of the centralised latin.c solver, we start by going over the input grid containing already-placed clue numbers, and calling latin_solver_place to enter each on into the solver's data structure. This has the side effect of ruling out each number from the rest of the row and column, and _also_ checking by assertion that the number being placed is not ruled out. Those are a bad combination, because it means that if you give an obviously inconsistent input grid to latin_solver_alloc (e.g. with two identical numbers in a row already), it will fail an assertion. In that situation, you want the solver run as a whole to return diff_impossible so that the error is reported cleanly. This assertion failure could be provoked by giving either Towers or Group a manually-constructed game description inconsistent in that way, and hitting Solve. Worse, it could be provoked during live play in Unequal, by filling in a number clashing with a clue and then pressing 'h' to get hints. [benh: Backported to 20191231: The latin_solver functions don't take a validator callback.] |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5030d87903191d581586ecda2382ad5bcd70f63d | 2023-02-05 |
| 0027-Pearl-fix-assertion-failure-on-bad-puzzle.patch | [PATCH 027/159] Pearl: fix assertion failure on bad puzzle. Similarly to the previous commit, if you started Pearl with at least some kinds of invalid puzzle (e.g. "6x6:abBfWcWWrBa") and then pressed 'h' to get hints, you could provoke an assertion failure. But this time the assertion wasn't in the solver itself; the solver gave up gracefully and didn't crash, but it _did_ leave the links between squares in the game_state in an inconsistent state, in that one square was marked as linking to its neighbour without the neighbour also linking back to it. This caused the /* should have reciprocal link */ assertion in dsf_update_completion to fail, when that was called from check_completion after the solver had finished, to decide whether the puzzle was now solved. In this commit, I arrange that whether or not pearl_solve returns a grid layout that's legal by the rules of the _puzzle_, it at least returns one that's legal by the rules of the _data representation_, in that every link between squares is either bidirectional or absent. This is a better solution than just removing the assertion, because if the inconsistent data were allowed to persist, it would lead to further problems in gameplay. For example, if you just remove that assertion instead of this fix and press 'h' on the example puzzle id above, you'll find that the non-reciprocal links are actually visible, in the form of several thick lines that stop at a grid square boundary instead of connecting two square-centres. (It looks even sillier if you set PEARL_GUI_LOOPY=y.) That's a situation that can't be created by a normal move, and if you try to make normal moves after it (e.g. click one of the weird edges), you'll find that both sides of the half-link get toggled, so now it's a half-link the other way round. So not only can't you _create_ this situation in normal play, you can't get rid of it either! That assertion in dsf_update_completion was commented out at one point, and I put it back in commit c5500926bf7458a saying that if it failed I'd like to know about it. And indeed, I'm glad I did, because this kind of unfixable wrongness in the resulting game_state was worth noticing and getting rid of! |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=05c536e50d0c3114e1de5283eac97ff22bad0fc7 | 2023-02-05 |
| 0028-Pearl-fix-bounds-check-in-previous-commit.patch | [PATCH 028/159] Pearl: fix bounds check in previous commit. Ahem. That's what I get for testing the fix on a square puzzle. |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9ce0a6d93212ffc0986a2b399fd8e9e983f62904 | 2023-02-05 |
| 0029-Unequal-Don-t-insist-that-solve-moves-must-actually-.patch | [PATCH 029/159] Unequal: Don't insist that solve moves must actually solve A corrupt save file can include an "S" move that doesn't give a valid solution. An assertion failure ("execute_move: Assertion `rc > 0' failed.") at that point is rude, so now we just don't set the "completed" flag in that case. We still set the "cheated" flag, to reward (lack of) effort. Here's a trivial test case: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :7:Unequal CPARAMS :1:3 PARAMS :1:3 DESC :17:0,0,0,0,0,0,0,0,0 NSTATES :1:2 STATEPOS:1:2 MOVE :10:S222222222 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=84ec2a0a77d63450311f7c25b36d4b9f7e3c53e1 | 2023-02-04 |
| 0030-Range-Don-t-fail-an-assertion-on-an-all-black-board.patch | [PATCH 030/159] Range: Don't fail an assertion on an all-black board If there are no white squares, then Range's check that all the white squares form a connected component goes wrong. Skip the check in that case to avoid an assretion violation ("edsf_canonify: Assertion `index >= 0' failed."). This can be demonstrated by starting a game with no clues (e.g. "range 3:i") and then filling in every square. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ae73ad76ef95f0e40868436cb750126322051dd0 | 2023-02-04 |
| 0031-Limit-width-and-height-to-SHRT_MAX-in-Mines.patch | [PATCH 031/159] Limit width and height to SHRT_MAX in Mines Mines' "struct set" stores co-ordinates within the grid in a pair of shorts, which leads to very bad behaviour (including heap-based buffer overruns) if the grid is bigger than SHRT_MAX in either dimension. So now we don't allow that. The overrun can be demonstrated by loading this save file, though the precise crash is quite variable. In particular, you seem to get better crashes if the file doesn't have a trailing newline. SAVEFILE:41:Simon Tatham's Portable Puzzle Collection PARAMS :5:06000 CPARAMS :7:6x60000 NSTATES :1:3 STATEPOS:1:2 MOVE :5:C0,00 GAME :5:Mines DESC :22:r8,u,00000000000000000 MOVE :: |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c0e08f308792b15425e10ad494263d77a45ad92d | 2023-01-28 |
| 0032-Mines-Add-assertions-to-range-check-conversions-to-s.patch | [PATCH 032/159] Mines: Add assertions to range-check conversions to short I think these should be adequately guarded by the new restrictions on grid size, but I'd prefer to be sure. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=49841bd0fc04490d94cf32c0e6f9d3f4ffabe098 | 2023-01-31 |
| 0033-Unequal-fix-sense-error-in-latin_solver_alloc-fix.patch | [PATCH 033/159] Unequal: fix sense error in latin_solver_alloc fix. In commit 5030d87903191d5 I gave latin_solver_alloc a return value, and introduced a check of that value at every call site. One of the checks was backwards, with the effect that Unequal game generation now more or less always fails an assertion. For example: $ unequal --generate 1 4#12345 |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=bd5c0a37a019c540eda05f8291cad90ffd598134 | 2023-02-08 |
| 0034-Forbid-impossible-moves-in-Bridges.patch | [PATCH 034/159] Forbid impossible moves in Bridges Specifically, a bridge or a non-bridge must connect two islands that differ in precisely one co-ordinate. Without this, a save file that tries to connect or disconnect two non-orthogonal islands will cause "island_join: Assertion `!"island_join: islands not orthogonal."' failed." Here's a save file demonstrating the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :7:Bridges PARAMS :13:3x3i30e10m2d0 CPARAMS :13:3x3i30e10m2d0 DESC :6:b1c1a2 NSTATES :1:2 STATEPOS:1:2 MOVE :10:L0,2,2,0,1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=bf9abb2a127a4a81babe50ecb419527f8aeffe28 | 2023-02-10 |
| 0035-Forbid-game-descriptions-with-joined-islands-in-Brid.patch | [PATCH 035/159] Forbid game descriptions with joined islands in Bridges A game description with islands in adjacent grid squares, like "3x3:11g", shouldn't be allowed. If it is, then bridges between the islands are invisible and clicking one of them causes an assertion The code to check this is really rather complex, but I think the complexity is mostly necessary. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=ad2fb760fc881d1ceb1ac1151bf60b85deb16c71 | 2023-02-10 |
| 0037-Check-state-is-valid-at-the-end-of-a-move-in-Pearl.patch | [PATCH 037/159] Check state is valid at the end of a move in Pearl A Pearl move string contains a sequence of sub-moves, each of which can affect the state of the connection between the centre of a square and one of its edges. interpret_move() generates these in pairs so that the two halves of a connection between the centres of adjacent squares stay in the same state. If, however, a save file contains mismatched half-moves, execute_move() should ideally return NULL rather than causing an assertion failure. This has to be checked at the end of the whole move string, so I've arranged for check_completion() to return a boolean indicating whether the current state (and hence the move preceding it) is valid. It now returns 'false' when a connection stops at a square boundary or when it goes off the board. These conditions used to be assertion failures, and now they just cause the move to be rejected. This supersedes the check for off-board connections added in 15f4fa8, since now check_completion() can check for off-board links for the whole board at once. This save file trivially demonstrates the problem, causing "dsf_update_completion: Assertion `state->lines[bc] & F(dir)' failed" without this fix: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :5:Pearl PARAMS :5:6x6t0 CPARAMS :5:6x6t0 DESC :17:BbBfWceBbWaBWWgWB NSTATES :1:2 STATEPOS:1:2 MOVE :6:R1,0,0 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c0b2f0fc98e87392dcb4dd8faf3076786fc49367 | 2023-02-11 |
| 0038-Cleanly-reject-more-ill-formed-solve-moves-in-Flood.patch | [PATCH 038/159] Cleanly reject more ill-formed solve moves in Flood The fix in e4112b3 was incomplete: there was another assertion that could be failed by a save file with an ill-formed solve move. That now gets rejected properly. Here's an example save file to demonstrate the problem: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :5:Flood PARAMS :7:6x6c6m0 CPARAMS :7:6x6c6m0 DESC :39:000000000000000000000000000000000000,00 NSTATES :1:2 STATEPOS:1:2 MOVE :1:S |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=896a73bd7ff8cbde44e97d89cef57346478f0072 | 2023-02-11 |
| 0039-Don-t-allow-moves-that-change-the-constraints-in-Une.patch | [PATCH 039/159] Don't allow moves that change the constraints in Unequal Unequal has a flags word per cell. Some of those flags are fixed, like the locations of the ">" signs, but others indicate errors and are used to allow the player to mark clues as "spent". Move strings beginning with "F" allow the user to change the "spent" flags, but they shouldn't allow the user to change any other flags, especially those marking the constraints. Without this fix, the following save file gives a "solver_nminmax: Assertion `x >= 0 && y >= 0 && x < o && y < o' failed" after it adds a clue that points off the board: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection GAME :7:Unequal PARAMS :3:3e0 CPARAMS :3:3e0 DESC :17:0,0,0,0,0,0,0,0,0 NSTATES :2:3 STATEPOS:1:3 MOVE :6:F2,0,4 MOVE :1:H |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=97b03cc67a31c1d0869a21c50b9ca31f78775ff9 | 2023-02-11 |
| 0041-Fix-memory-leaks-in-Keen-s-validate_desc.patch | [PATCH 041/159] Fix memory leaks in Keen's validate_desc() Keen uses a DSF to validate its game descriptions and almost always failed to free it, even when the validation succeeded. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=bb31efdbc91495a4385ca0afffa4c8bb8f564d7b | 2023-02-13 |
| 0043-Don-t-leak-grids-in-Loopy-s-validate_desc.patch | [PATCH 043/159] Don't leak grids in Loopy's validate_desc() | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=11b631ea870355306c4b1d03458bb3cea8f29188 | 2023-02-13 |
| 0044-Remember-to-free-the-to_draw-member-from-Net-s-draws.patch | [PATCH 044/159] Remember to free the to_draw member from Net's drawstate | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=493bf16ddbe2185664d6c3053f7891a9f232c75c | 2023-02-13 |
| 0045-Undead-check-the-return-value-of-sscanf-in-execute_m.patch | [PATCH 045/159] Undead: check the return value of sscanf() in execute_move() sscanf() assigns its output in order, so if a conversion specifier fails to match, a later "%n" specifier will also not get its result assigned. In Undead's execute_move(), this led to the result of "%n" being used without being initialised. That could cause it to try to parse arbitrary memory as part of the move string, which shouldn't be a security problem (since execute_move() handles untrusted input anyway), but could lead to a crash and certainly wasn't helpful. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=0a7c531e8f4c1970662f7c30aea006e65d5ff010 | 2023-02-13 |
| 0046-Don-t-leak-duplicate-edges-in-Untangle.patch | [PATCH 046/159] Don't leak duplicate edges in Untangle Untangle game descriptions are allowed to contain duplicate edges, and add234() can handle deduping them. However, when add234() reports that your newly-allocated edge is a duplicate, it's important to free it again. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=19401e95e0a75577103e9c1a877611234a0d8ab5 | 2023-02-13 |
| 0047-Remember-to-free-the-numcolours-array-from-Pattern-s.patch | [PATCH 047/159] Remember to free the numcolours array from Pattern's drawstate [benh: Backported to 20191231: Adjust context] |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=1aa67e7a75ac21d15780d6aaab65a2c0f6f65198 | 2023-02-13 |
| 0049-Twiddle-don-t-read-off-the-end-of-parameter-strings-.patch | [PATCH 049/159] Twiddle: don't read off the end of parameter strings ending 'm' The overrun could be demonstrated by specifying a parameter string of "3x3m" to a build with AddressSanitizer. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=73c7bc090155ab8c4661feaeea9e6a6e74ee6f77 | 2023-02-13 |
| 0050-Loopy-free-the-grid-description-string-if-it-s-inval.patch | [PATCH 050/159] Loopy: free the grid description string if it's invalid | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e336513be755159158c5ba017c91b018ad4cd36c | 2023-02-13 |
| 0052-Avoid-division-by-zero-in-Cube-grid-size-checks.patch | [PATCH 052/159] Avoid division by zero in Cube grid-size checks On a triangular grid, Cube allows either d1 or d2 (but not both) to be zero, so it's important to check that each one is not zero before dividing by it. The crash could be triggered by, for instance "cube t0x2". |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=df783b93e3271264a8d54f90876f41a80ef2247d | 2023-02-13 |
| 0055-Validate-that-save-file-values-are-ASCII-mostly.patch | [PATCH 055/159] Validate that save file values are ASCII (mostly) Apart from "SEED" records, all values in save files generated by Puzzles should be printable ASCII. This is enforced by assertion in the saving code. However, if a save file with non-ASCII move strings (for instance) manages to get loaded then these non-ASCII values can cause an assertion failure on saving. Instead, the loading code now checks values for ASCIIness. This will not only avoid problems when re-saving files, but will also defend the various internal parsers from at least some evil strings. It shouldn't invalidate any save files actually generated by Puzzles, but it will sadly invalidate some of my fuzzing corpus. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c3a5a7842eb6c41fb75a8a110a3f2cbc1c8fc5d9 | 2023-02-12 |
| 0056-More-validation-of-solve-moves-in-Flood.patch | [PATCH 056/159] More validation of solve moves in Flood To avoid assertion failures while painting it, we need to ensure that the purported solution in a solve move doesn't include filling with the current top-left colour at any point. That means checking the first entry against the current top-left colours, and each later one against its predecessor. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e8668dc883e940f0852ff4520abc3d30cae90aef | 2023-02-13 |
| 0058-Make-sure-that-moves-in-Flood-use-only-valid-colours.patch | [PATCH 058/159] Make sure that moves in Flood use only valid colours If execute_move() receieves a move that uses a colour beyond the range for the current game, it now rejects it. Without this a solve string containing an invalid colour would cause an assertion failure: "fill: Assertion `oldcolour != newcolour' failed." While I was in the area I put a range check on colours for normal moves as well. To demonstrate the problem, load this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Flood PARAMS :7:6x6c6m5 CPARAMS :7:6x6c6m3 DESC :39:432242034203340350204502505323231342,17 NSTATES :1:2 STATEPOS:1:2 MOVE :2:S6 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=7364ce8e266d947be146d635958a7b282752aac6 | 2023-02-14 |
| 0059-Tighten-grid-size-limit-in-Mines.patch | [PATCH 059/159] Tighten grid-size limit in Mines Mines uses random_upto() to decide where to place mines, and random_upto() takes a maximum limit of 2^28-1, so limit the number of grid squares to that (or INT_MAX if someone's still trying to build on a 16-bit system). This avoids an assertion failure: "random_upto: Assertion `bits < 32' failed." which can be demonstrated by this save file: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :5:Mines PARAMS :5:18090 CPARAMS :5:18090 DESC :11:r9,u,MEdff6 UI :2:D0 TIME :1:0 NSTATES :1:2 STATEPOS:1:2 MOVE :4:O2,1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9394e9c74bdb48dc1c74693bcb41fd35f8fc743c | 2023-02-15 |
| 0061-Solo-cope-with-pencil-marks-when-tilesize-1.patch | [PATCH 061/159] Solo: cope with pencil marks when tilesize == 1 Solo's layout calculations for pencil marks could fail with a tilesize of 1, generating an assertion failure: "draw_number: Assertion `pbest > 0' failed." This was reported as Debian bug #905852. My solution is slightly silly, namely to change a ">" in the test for whether a new layout is the best so far to ">=". This allows for finding a (terrible) layout even for tilesize == 1, and also has the side-effect of slightly preserring wide layouts over tall ones. Personally, I think that's an improvement. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=3cd51d001769c657ebb4184bd05343af4d7e12b1 | 2023-02-16 |
| 0065-Tracks-set-drag_s-x-y-even-if-starting-off-grid.patch | [PATCH 065/159] Tracks: set drag_s{x,y} even if starting off-grid Otherwise, if subsequent mouse/finger movement lines up with the previous drag attempt's start, then suddenly a drag is in progress from there, which is confusing. Fixes #588 (cherry picked from Android port, commit 8ce1bbe460d70a915caf2dbeb30354d22dc8a8ef) |
Chris Boyle <chris@boyle.name> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=111db0743bd273c340dd683449076fd9ec5797f5 | 2023-02-10 |
| 0080-Undead-be-a-bit-more-careful-about-sprintf-buffer-si.patch | [PATCH 080/159] Undead: be a bit more careful about sprintf buffer sizes | Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=448095ede815b1a63ddedc602c3ac768a0d52968 | 2023-02-18 |
| 0090-Fix-memory-leak-in-midend_game_id_int.patch | [PATCH 090/159] Fix memory leak in midend_game_id_int() The "par" string wasn't getting freed on some error paths. Fixed by freeing it immediately after its last use, which is before any of the error paths. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=4e09175fdaaffc0483fc9bf767311268794d956c | 2023-02-20 |
| 0092-Flood-don-t-read-off-the-end-of-some-parameter-strin.patch | [PATCH 092/159] Flood: don't read off the end of some parameter strings This is essentially the same fix as 73c7bc090155ab8c was for Twiddle. The new code is less clever but more correct (and more obviously correct). The bug could be demonstrated by using a parameter string of "c" or "m" with an AddressSanitizer build of Flood. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=bbe866a3819c6a754a5b1d8c5bc5d0701796acfb | 2023-02-20 |
| 0101-Be-more-careful-with-type-of-left-operand-of.patch | [PATCH 101/159] Be more careful with type of left operand of << On a 32-bit system, evaluating 1<<31 causes undefined behaviour because 1 is signed and so it produces signed overflow. UBSan has spotted a couple of occasions where this happens in Puzzles, so in each case I've converted the left operand to the unsigned result type we actually want. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=93be3f7ccaa63b0fd953bcfd88d685b47b76605e | 2023-02-26 |
| 0102-Map-reduce-maximum-size.patch | [PATCH 102/159] Map: reduce maximum size validate_desc relies on being able to calculate 2*wh in an int, so the maximum grid size is at most INT_MAX/2. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e2d390aae872cee4cb16d746af3b2eeb7713cbf5 | 2023-02-26 |
| 0103-Correctly-handle-some-short-save-files.patch | [PATCH 103/159] Correctly handle some short save files A save file that ended in the middle of a value before the "SAVEFILE" field had been loaded would cause a read from uninitialised memory. While technically undefined behaviour this was practically pretty harmless. Fixed by handling unexpected EOF here the same an unexpected EOF anywhere else. This bug could be demonstrated by loading a truncated save file like this in a build with MemorySanitizer enabled: SAVEFILE:41:Simo |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=6ee62a43abe7d7e77226415b21d1cbf16dbda85a | 2023-02-26 |
| 0104-Inertia-insist-that-solutions-must-be-non-empty.patch | [PATCH 104/159] Inertia: insist that solutions must be non-empty Any solution actually generated by the solver will contain at least one move, because it refuses to solve games that are already solved. However, a save file might contain an empty "solve" move. This causes an uninitialised read when execute_move() then tries to check if the next move is in accordance with the solution, because the check for running off the end of the solution happens after that. We now avoid this by treating a zero-length "solution" as an invalid move. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5a491c5ad333ef34c1e7713f920f51cbb205af60 | 2023-02-26 |
| 0115-Galaxies-fix-recursion-depth-limit-in-solver.patch | [PATCH 115/159] Galaxies: fix recursion depth limit in solver. The static variable 'solver_recurse_depth' is _mostly_ used by the standalone solver, to appropriately indent the solver diagnostics for the current recursion level. So most uses of it are guarded by an '#ifdef STANDALONE_SOLVER' statement, or some equivalent (such as being inside the solvep() macro). One exception is the check that limits the recursion depth to 5, to avoid getting hung up forever on a too-hard game. Unfortunately, this check depends on the variable actually incrementing when we recurse another level - and it wasn't, because the increment itself was under ifdef! So the generator in live Galaxies could recurse arbitrarily deep, and generate puzzles that the standalone solver found too hard _even_ at Unreasonable mode. Removed the ifdefs, so that solver_recurse_depth is now incremented and decremented. Also, make sure to initialise the depth to 0 at the start of a solver run, just in case it had a bogus value left over from a previous run. |
Simon Tatham <anakin@pobox.com> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=f018ef97d34b9126744e63cc2112c302fcae4ab4 | 2023-03-12 |
| 0138-Correct-a-range-check-in-Magnets-layout-verification.patch | [PATCH 138/159] Correct a range check in Magnets' layout verification Squares in the grid are numbered from 0, so the upper limit check needs to use "<=" rather than "<". Without this, invalid descriptions can cause a read overrun off the end of the board. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=91735e5019be84d2fa693c5d40746c818ace28f8 | 2023-03-31 |
| 0139-Magnets-add-a-check-that-magnets-don-t-wrap-between-.patch | [PATCH 139/159] Magnets: add a check that magnets don't wrap between lines There was nothing in Magnet's description validation to prevent there being the left end of a magnet at the right end of a row and the right end of a magnet at the left end of the row below. Indeed as far as I can such a game (e.g. 3x3:..2,2..,...,1.1,TLRB*LRLR) plays entirely correctly except that one magnet is discontinuous. While this worked, it was entirely an artefact of the particular memory layout that Magnets uses and shouldn't have been allowed, so I've added an additional validation rule to stop it. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=0bd1a8057841386754f9f4a8a268616c7ce80e80 | 2023-04-01 |
| 0155-Net-assert-that-cx-and-cy-are-in-range-in-compute_ac.patch | [PATCH 155/159] Net: assert that cx and cy are in range in compute_active() This avoids an out-of-range heap write shortly afterwards. An assertion failure is better than a buffer overrun, but still not ideal. Fixing the problem properly will require fairly wide-ranging changes, though. The bug can be demonstrated by loading this save file into a build with AddressSanitizer: SAVEFILE:41:Simon Tatham's Portable Puzzle Collection VERSION :1:1 GAME :3:Net PARAMS :4:5x5w CPARAMS :4:5x5w DESC :25:9893e85285bb72e6de5182741 UI :9:O0,0;C6,6 NSTATES :1:1 STATEPOS:1:1 |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e411db788cfc0d0ed54b3c9b9deb15edba7d237a | 2023-02-13 |
| 0159-Don-t-allow-zero-clues-in-Pattern.patch | [PATCH 159/159] Don't allow zero clues in Pattern Some nonogram implementations allow zero clues so that a row or column with a single zero clue is equivalent to one with no clues, that is it has no black squares in it. Pattern, however, doesn't interpret them like this and treats a puzzle with a zero clue as insoluble, so it's not helpful to permit them. Permitting zero clues also confuses Pattern's memory allocation so that it can suffer a buffer overrun. As an example, before this commit a build with AddressSanitizer would report a buffer overrun with the description "1:0/0.0" because it tries to put two clues in a row that can have a maximum of one. |
Ben Harris <bjh21@bjh21.me.uk> | no | debian | https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=71cf891fdc3ab237ecf0e5d1aae39b6c9fe97a4d | 2023-02-14 |