From: Junio C Hamano <gitster@pobox.com>
To: "Kristoffer Haugsbakk" <code@khaugsbakk.name>
Cc: "Tiago Pascoal" <tiago@pascoal.net>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git column fails (or crashes) if padding is negative
Date: Fri, 09 Feb 2024 09:57:59 -0800 [thread overview]
Message-ID: <xmqqttmhfrko.fsf@gitster.g> (raw)
In-Reply-To: <571fb353-af1d-4cc9-a2c2-197296685623@app.fastmail.com> (Kristoffer Haugsbakk's message of "Fri, 09 Feb 2024 17:27:59 +0100")
"Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:
> ```
> $ seq 1 24 | git column --mode=column --padding=-1
> 12345678910<binary?><numbers>
> $ seq 1 24 | git column --mode=column --padding=-3
> fatal: Data too large to fit into virtual memory space.
> $ seq 1 24 | git column --mode=column --padding=-5
> fatal: Out of memory, malloc failed (tried to allocate 18446744073709551614 bytes)
> ```
>
> This is an “Internal helper command” under the “plumbing” suite. And I
> get the impression that sometimes these fallthroughs are treated as
> “don’t do that”. But I don’t know.
If the nonsense input is easy to tell, then telling "don't feed
nonsense input" to the user while rejecting such nonsense input
would be a good idea.
> On the other hand it failing inside malloc looks weird. Why not catch
> this before the malloc call is made?
Presumably, the parameter we prepare before calling malloc() is of
unsigned type, and feeding a negative value to such a callchain
would cast it to a large unsigned value?
Indeed, whereever cops.padding is referenced in column.c, it clearly
is assumed that it is a non-negative value. *width accumulates the
width of data items plus padding, and it also is used to divide some
number to arrive at the number of columns, so by tweaking the padding
to the right value, you probably should be able to cause division by
zero, too, in column.c:layout().
Hopefully the attached would be a good place to start (I am not
going to finish it with log message, tests, and fixes to other
places).
builtin/column.c | 2 ++
column.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git c/builtin/column.c w/builtin/column.c
index e80218f81f..8537d09d2b 100644
--- c/builtin/column.c
+++ w/builtin/column.c
@@ -45,6 +45,8 @@ int cmd_column(int argc, const char **argv, const char *prefix)
memset(&copts, 0, sizeof(copts));
copts.padding = 1;
argc = parse_options(argc, argv, prefix, options, builtin_column_usage, 0);
+ if (copts.padding < 0)
+ die(_("--padding must be non-negative"));
if (argc)
usage_with_options(builtin_column_usage, options);
if (real_command || command) {
diff --git c/column.c w/column.c
index ff2f0abf39..9cc703832a 100644
--- c/column.c
+++ w/column.c
@@ -189,7 +189,7 @@ void print_columns(const struct string_list *list, unsigned int colopts,
memset(&nopts, 0, sizeof(nopts));
nopts.indent = opts && opts->indent ? opts->indent : "";
nopts.nl = opts && opts->nl ? opts->nl : "\n";
- nopts.padding = opts ? opts->padding : 1;
+ nopts.padding = (opts && 0 < opts->padding) ? opts->padding : 1;
nopts.width = opts && opts->width ? opts->width : term_columns() - 1;
if (!column_active(colopts)) {
display_plain(list, "", "\n");
@@ -373,7 +373,7 @@ int run_column_filter(int colopts, const struct column_options *opts)
strvec_pushf(argv, "--width=%d", opts->width);
if (opts && opts->indent)
strvec_pushf(argv, "--indent=%s", opts->indent);
- if (opts && opts->padding)
+ if (opts && 0 < opts->padding)
strvec_pushf(argv, "--padding=%d", opts->padding);
fflush(stdout);
next prev parent reply other threads:[~2024-02-09 17:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 14:21 git column fails (or crashes) if padding is negative Tiago Pascoal
2024-02-09 16:27 ` Kristoffer Haugsbakk
2024-02-09 17:57 ` Junio C Hamano [this message]
2024-02-11 17:08 ` Kristoffer Haugsbakk
2024-02-12 16:37 ` Junio C Hamano
2024-02-09 17:52 ` [PATCH] column: disallow negative padding Kristoffer Haugsbakk
2024-02-09 18:26 ` Kristoffer Haugsbakk
2024-02-10 9:48 ` Chris Torek
2024-02-11 17:10 ` Kristoffer Haugsbakk
2024-02-11 17:55 ` Junio C Hamano
2024-02-11 18:18 ` Kristoffer Haugsbakk
2024-02-11 19:27 ` [PATCH v2] " Kristoffer Haugsbakk
2024-02-11 22:47 ` Rubén Justo
2024-02-11 23:50 ` Rubén Justo
2024-02-12 7:05 ` Kristoffer Haugsbakk
2024-02-12 16:50 ` Kristoffer Haugsbakk
2024-02-12 21:28 ` Rubén Justo
2024-02-13 16:01 ` [PATCH v3 0/2] " Kristoffer Haugsbakk
2024-02-13 16:01 ` [PATCH v3 1/2] " Kristoffer Haugsbakk
2024-02-13 16:01 ` [PATCH v3 2/2] column: guard against " Kristoffer Haugsbakk
2024-02-13 17:06 ` Junio C Hamano
2024-02-13 18:39 ` Rubén Justo
2024-02-13 19:39 ` Junio C Hamano
2024-02-13 19:56 ` Rubén Justo
2024-02-13 20:35 ` Kristoffer Haugsbakk
2024-02-13 20:59 ` Junio C Hamano
2024-02-13 23:25 ` Rubén Justo
2024-02-13 23:36 ` [PATCH] tag: error when git-column fails Rubén Justo
2024-02-14 1:35 ` Junio C Hamano
2024-02-13 19:27 ` [PATCH v3 0/2] column: disallow negative padding Rubén Justo
2024-02-13 20:32 ` Kristoffer Haugsbakk
2024-02-13 20:58 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqttmhfrko.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=tiago@pascoal.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).