I have committed the error handling aspects of the patch.
Turns out that we have yet another possibility to trigger a theoretical
signed integer overflow if pwd_tries is INT_MAX. This one avoids such
situation as well.
Okay?
Index: local_passwd.c
On Fri, May 05, 2023 at 11:00:12AM -0600, Todd C. Miller wrote:
> This looks OK but I'd like to see an error message if waitpid()
> really does fail. How about something like this, which also avoid
> needing the extra variable?
Yes, looks much better!
Index: local_passwd.c
Hi,
this patch fixes error paths and an undefined behaviour:
In getnewpasswd we increment "tries" every time we try to enter a new
password. The code allows this to be repeated endlessly by defining
passwordtries to be 0 in /etc/login.conf. But unfortunately we even
increment the int "tries" if
On Tue, Apr 19, 2022 at 09:10:13AM -0600, Theo de Raadt wrote:
> - if ((buf->buf = malloc(len)) == NULL) {
> + if (len == 0)
> + buf->buf = NULL;
> + else if ((buf->buf = malloc(len)) == NULL) {
>
> This code intentionally permitted malloc(0), because with our
: regress/lib/libutil/imsg/ibuf_test.c
diff -N regress/lib/libutil/imsg/ibuf_test.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ regress/lib/libutil/imsg/ibuf_test.c19 Apr 2022 13:04:00 -
@@ -0,0 +1,172 @@
+/* $OpenBSD$
+*/
+/*
+ * Copyright (c) Tobias Stoeckmann
+ *
+ * Permission
On Fri, Dec 31, 2021 at 10:29:28PM -0800, Philip Guenther wrote:
> To bikeshed slightly I would be inclined to do the work progressively,
> perhaps like the diff below...but your diff works too.
I'm fine with your version as well.
In fact I have used a comparable approach but opted out to the
Hi,
it is possible to trigger a use after free bug in less with huge
files or tight memory constraints. PoC with 100 MB file:
dd if=/dev/zero bs=1024 count=102400 | tr '\0' 'a' > less-poc.txt
ulimit -d 157286
less less-poc.txt
The linebuf and attr buffers in line.c are supposed to never be
Hi,
this merges latest bugfixes from upstream to our version of less.
No new features introduced. Upstream commits and issues are linked as
references.
brac.c:
Signed integer overflow with huge files.
https://github.com/gwsw/less/pull/210
Hi,
upstream (greenwood) less has disabled history file support for secure
mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201
The problem was about permanent marks for which we do not have support
anyway. Users could possibly access files they should not be able to.
Since upstream
This patch avoids a possible integer overflow on excessively large
amount of events added to an event base in kqueue mode (default).
Just as with previous changes, this is very unlikely to trigger and
is a just a defensive measure.
Changes in this diff:
* KNF (sorted imports and added limits.h
It is possible to trigger an endless loop or out of boundary write
on 64 bit systems with evbuffer_readline calls for buffers which
exceed 4 GB (i.e. overflow uint).
for (i = 0; i < len; i++)
Variable i is unsigned int and len size_t. This leads to an endless
loop if len is larger than
On Tue, Apr 30, 2019 at 07:13:55PM +0200, Jeremie Courreges-Anglas wrote:
> > So the diff below removes the fallback path and all associated code and
> > variables.
>
> > I have left out some minor cleanups for now to ease reviews.
>
> Here's a diff that amends the signature of gettime() and
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file:
On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> ah, good catch. I don't think it's wrong (until it overflows) but needs to be
> fixed. Needs some more review then. Thanks.
I have added following changes:
- converted 0u to 0 as bluhm pointed out
- converted -1 to SIZE_MAX whereever
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file:
On Wed, Apr 17, 2019 at 11:34:36AM -0400, Ted Unangst wrote:
> (and then reformat to be knf, but after changes that require review.)
Totally agree here. That will help with further changes to this file!
>
> Index: min_heap.h
> ===
I would like to protect min_heap_push against integer overflows,
which could either be triggered on a 64 bit system with massive
amounts of RAM (to overflow s->n) or on a 32 bit system with tight
memory layout (overflowing a * sizeof *p).
Both cases are basically not possible to be triggered, but
On Fri, Jul 20, 2018 at 06:51:33PM -0500, Scott Cheloha wrote:
> tobias@ spotted this one a few months ago when reviewing a different
> diff of mine.
Yeah, I remember that one. Brings up memories of another diff of that
time as well.
> ... ok as-is?
Yeah, okay by me as well.
Tobias
As tb@ pointed out, u64ton can overflow on ULONG_MAX. It could also
happen on systems with 64 bit int and INT_MIN, although we don't have
such a system supported by our code base.
You can reach the u64ton function by printing the length of a string
within a variable like this:
$ a=string
$ echo
On Wed, Apr 04, 2018 at 01:30:52PM +0200, Theo Buehler wrote:
> > +/* convert uint64_t to base N string */
> >
> > char *
> > -ulton(long unsigned int n, int base)
> > +u64ton(uint64_t n, int base)
> > {
> > char *p;
> > static char buf [20];
>
> I don't think it's actually an issue
Hi,
this patch increases the number range on 32 bit architectures like
i386 to 64 bit. These are already supported on 64 bit architectures
due to using "long".
The rational behind this patch is to unify test/expr/ksh in allowing
64 bit integers, making variable handling more consistent in base
Hi,
On Sat, Mar 31, 2018 at 02:57:45AM +0200, Ingo Schwarze wrote:
> Even though - as discussed previously for test(1) - behaviour is
> undefined by POSIX outside the range 0 to 2147483647, we are allowed
> to handle a larger range, and i agree that handling the range
> -9223372036854775808 to
Our expr implementation supports 64 bit integers, but does not check
for overflows during parsing and arithmetical operations.
This patch fixes the problems based on FreeBSD's implementation, which
is a bit more advanced than NetBSD, which it is based upon.
The added regression test case is
On Wed, Mar 28, 2018 at 12:25:01PM +0200, Otto Moerbeek wrote:
> Hmm, on what platform are you doing this? I could not reproduce your
> problem on arm64 -current,
To sum it up: It was my fault, -current is all fine.
The issue can be reproduced with 6.2-stable amd64 and somewhere between
Hi,
On Wed, Mar 28, 2018 at 12:53:47AM +0200, Ingo Schwarze wrote:
> Ouch, you are right. But then, the code feels counter-intuitive
> and the error message confusing.
I agree. Talking about a zero out of nothing seems weird, even though
I have learned yesterday that "a=''; echo $((a))" is "0".
On Tue, Mar 27, 2018 at 11:47:27PM +0200, Ingo Schwarze wrote:
> See inline for one optional suggestion.
>
> > if (!stop || !start)
> > errx(1, "[-bcf] list: values may not include zero");
>
> Consider deleting these two lines, too.
>
> You new function
On Tue, Mar 27, 2018 at 10:36:17PM +0200, Ingo Schwarze wrote:
> > + int sig;
>
> Drop this variable, it does no good but only harm.
Yeah, too bad that I didn't notice this left-over from a previous
development step. Strange enough that regression tests didn't
choke on it...
> > + /* skip
Hi,
On Tue, Mar 27, 2018 at 09:05:12PM +0200, Klemens Nanni wrote:
> FWIW, see "test: Catch integer overflow, fail on trailing whitespaces"
> from 24.07.2017 on tech@:
>
> https://marc.info/?l=openbsd-tech=150091968903042
sorry I didn't intend to ignore your mail. I didn't follow
The test(1) utility is prone to integer overflows on 64 bit systems.
By using strtol and casting the result to an int, it is possible to
run tests which succeed even though they should fail:
$ arch
OpenBSD.amd64
$ /bin/test 4294967296 -eq 0; echo $?
0
I could have chosen the way of FreeBSD,
Resending this old diff. Adjusted to apply with -current source:
Illegal fragmentation block sizes can trigger division by zero in the
disklabel and fsck_ffs tools.
See this sequence of commands to reproduce:
# dd if=/dev/zero of=nofrag.iso bs=1M count=1
# vnconfig vnd0 nofrag.iso
# disklabel
This patch fixes an out of boundary write in cut:
$ cut -c 2147483648 -
Segmentation fault (core dumped)
The supplied number can be parsed by strtol, but the result is casted
into a signed int, therefore turning negative. Afterwards, it is used
as an offset into a char array to write data at the
On Fri, Mar 23, 2018 at 10:48:03AM +0100, Tobias Stoeckmann wrote:
> My initial mail was sent with quoted-printable mime type, which means
> that it looks quite garbled. Sorry for that, this mail contains the same
> patch but is sent 7bit encoded.
Seems to be an issue with an overly lon
My initial mail was sent with quoted-printable mime type, which means
that it looks quite garbled. Sorry for that, this mail contains the same
patch but is sent 7bit encoded.
Also, the decision was made to commit this after 6.3 release. I like
that decision, after all we will have more time to
Hi,
this patch merges FreeBSD bin/95079 into our apply(1) implementation.
As we do not have an sbuf implementation, I have reworked the code
to properly handle string operations. Turns out that this fixes an
out of boundary write as well and made the code much more readable.
While reviewing the
Hi,
On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> While freeing tag entries, make sure to free the copied strings.
this patch looks good to me.
Have you reported this to the upstream less maintainers, as well?
The original less and the forked one from Garrett D'Amore, which
On Sun, Feb 21, 2016 at 07:04:27PM +0100, Martin Natano wrote:
> The expected order of lines would be, x, y, z but patch produces y, z, x
> instead. The first line is inserted at the correct position, but then
> the other lines are inserted before the first one. The following diff
> solves that
On Sun, Feb 21, 2016 at 05:15:34PM +0100, Martin Natano wrote:
> While testing your suggestion with the example I run into a bug with
> ed-style diff handling in patch(1), resulting in incorrect output
> (fix in the works). Applying the generated diff with ed(1) works fine,
> though.
Yeah, patch
On Sat, Dec 05, 2015 at 06:26:35AM -0500, Ted Unangst wrote:
> may i suggest strlen(s) instead of strchr(s, 0)?
There's actually one part in newfs' code that uses this. And in theory
it has the same issue, not checking if s (which is special, which might
be argv[0]) is empty. I highly doubt this
> Index: gen/getusershell.c
> ===
> RCS file: /cvs/src/lib/libc/gen/getusershell.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 getusershell.c
> --- gen/getusershell.c14 Sep 2015 16:09:13 - 1.16
> +++
On Sat, Dec 05, 2015 at 01:25:10PM -0500, Ted Unangst wrote:
> ok. i was going to leave the behavior alone, but we can fix that too.
>
> - use getline to read lines of any length.
> - only consider lines that start with a /.
> - truncate lines after a #, but not after spaces.
ok tobias, thanks
Here's the spin-off from previous __progname patch.
It's possible to have an out-of-boundary read in newfs_ext2fs when
supplying an empty partition name. Before calling strchr() - 1, it should
be verified that it's not empty. While at it, the result of the strchr call
will never be NULL, because
On Sat, Dec 05, 2015 at 03:29:06AM -0500, Ted Unangst wrote:
> looks good, but you've got some mostly unrelated changes in here. this should
> be separate, but ok for the rest.
It started with a "check argv" code review and ended up with __progname
adjustments, so I agree here and removed the
Hi Ingo,
On Fri, Dec 04, 2015 at 12:27:39PM +0100, Ingo Schwarze wrote:
> uint32_t should be preferred because that's the POSIX type, while
> u_int32_t is not standardized. If you are working on the file
> anyway, i'd recommend to unify all uses to uint32_t.
done.
> __LP64__ that is overly
There's still a possible overflow in getusershell.c. We could increase
the buffer allocation yet again, but I have to agree with the glibc
developers here: enough is enough. The code is ugly and has proven to be
difficult to review.
The overflow has been spotted by Paul Pluzhnikov, after I
Thanks Ingo for your extensive review! It contains lots of valuable
input for me.
I have applied all your recommendations, they make a lot of sense.
> I would suggest to use uint32_t.
Just while applying this, I noticed that the file has a mix of the
types u_int32_t and uint32_t. I took
Hi,
this patch adds a lot of input validation to libc/locale/rune.c.
The kind of validations are borrowed from my nls changes some
weeks ago.
I've contacted stsp@ about this. I think it's ready to get more
review from tech@. Let me know what you think!
Tobias
Index: rune.c
Here's an updated diff:
- use "overflow" error message for snprintf and friends
- use err instead of errx for out of memory conditions
- if fatal() doesn't print error string, use ": %s", strerror(errno)
Is this okay for ssh and tmux, which are out to be very portable?
Nicholas mentioned that
On Sat, Nov 07, 2015 at 05:57:55PM -0500, Ted Unangst wrote:
> > Also, I'm seeing a couple "could not allocate memory" messages added to
> > *snprintf() functions. They write to a supplied buffer, no?
>
> Good catch.
Will update that one, thanks.
> > > > + i = vsnprintf(str, len, fmt,
On Thu, Nov 05, 2015 at 03:57:26PM +, Nicholas Marriott wrote:
> I like this a lot.
>
> There are some trivial differences in the various xmalloc.h as well, and
> I think you could make the style consistent within the files (eg "return
> i" in xasprintf and xsnprintf).
Oh yes, forgot to
On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote:
> I don't know why cvs and rcs xmalloc.c has ended up so different.
It's not just about cvs and rcs:
/usr/src/usr.bin/cvs/xmalloc.c
/usr/src/usr.bin/diff/xmalloc.c
/usr/src/usr.bin/file/xmalloc.c
/usr/src/usr.bin/rcs/xmalloc.c
I wouldn't call this definition readable:
void
cvs_ent_line_str(const char *name, char *rev, char *tstamp, char *opts,
char *sticky, int isdir, int isremoved, char *buf, size_t len)
So what about changing it to return allocated memory by itself,
which would mean changing the internals from
On Sun, Nov 01, 2015 at 11:17:40AM +, Stuart Henderson wrote:
> On 2015/11/01 08:03, Nicholas Marriott wrote:
> > Some did for a while but it has some nasty bugs and nobody is working on
> > fixing it.
>
> Some used it on amd64 for a while to avoid checkout failures due to
> running into
On Fri, Oct 30, 2015 at 08:52:02AM +0800, Michael W. Bombardieri wrote:
> Sorry. Here is new diff. Hopefully I haven't missed anything else.
You missed OpenCVS, which shares the same code base.
But is OpenCVS worth it anymore?
Even a harsher question: Is it time to tedu it?
> Comments / oks?
Looks much cleaner, okay for me.
$ sed s/a/b/ /nofile
sed: 0: /nofile: /nofile
That message doesn't tell me a lot, let's better write
strerror(errno) if fopen returns NULL:
$ ./sed s/a/b/ /nofile
sed: 0: /nofile: No such file or directory
Index: main.c
===
RCS
On Fri, Oct 23, 2015 at 09:19:34PM +0200, Stefan Sperling wrote:
> Now that this is committed, do you intend to audit the runes code as
> well? :-)
Hah, yeah that's the next logical step to do. Except you are faster
than me, then I would probably okay it. ;)
The library function nlist(3) does not properly validate parsed ELF
binary files, which can lead to out of boundary accesses.
Also, nlist will return -1 for stripped binary files, because eventually
it will try to mmap 0 bytes. Instead of returning the amount of symbols
we tried to look up, -1
On Thu, Oct 15, 2015 at 11:28:07AM -0600, Todd C. Miller wrote:
> Those checks all look good. The only thing I had a question
> about is the:
>
> len = strlen(sym);
>
> Would it be better to use memchr to search for the NUL terminator
> to avoid going past the end? E.g.
>
> if
ed.c
.include
Index: ed.c
===
RCS file: ed.c
diff -N ed.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ed.c13 Oct 2015 16:33:09 -
@@ -0,0 +1,340 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Tobias Stoeckmann <tob...@openbsd.org>
+ *
+ * Permission to use, copy, modify, a
On Tue, Oct 13, 2015 at 06:43:31PM +0200, Tobias Stoeckmann wrote:
> - Check for our new /.// substitution expression
> - Be more restrictive about command parsing, so we do not
> allow commands like "10insert" instead of "10i".
And now, fix regression whic
ndex: ed.c
===
RCS file: ed.c
diff -N ed.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ed.c11 Oct 2015 09:43:59 -
@@ -0,0 +1,335 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Tobias Stoeckmann <tob...@openbsd.org>
+ *
+ * Permission to use, copy, modify
That's what I get for copy out of a manual...
The LIST_EMPTY example lacks an opening curly bracket. The other
examples have it, so it's a pretty obvious fix.
Index: queue.3
===
RCS file: /cvs/src/share/man/man3/queue.3,v
GNU patch only allows s/.// as a regular expression in substitutions.
Our diff implementation writes s/^\.\././ which is basically the same,
because they are used to change ".." lines into ".".
This is required if an ed-formatted diff tries to create a line that
only has a dot in it. Normally,
By the way, this is the second version with miod's feedback. Time to
send it to tech@ now, too.
Fixed one issue due to missing braces and less ntohl() calls, which
makes the code easier to read.
Index: catopen.c
===
RCS file:
On Sat, Sep 19, 2015 at 05:57:23PM -0400, Michael McConville wrote:
> If you're abstracting something into a function, it definitely shouldn't
> be creating more code.
Yet this shouldn't stop you from performing "divide and conquer". It's
not just about reducing lines of code when abstracting
The function pr_pack does not properly check boundaries before
accessing packet data. This could happen on short network reads or
when we receive packets that are addressed for another running ping6
instance (see pr_pack comment for more information).
Index: ping6.c
Don't allow negative numbers for font width, because it could lead to a
floating point exception (and wouldn't make sense anyway).
# wsfontload -w -7 /dev/null
Floating point exception (core dumped)
# _
While at it, use strtonum for proper error messages; also check font height.
Current error
Okay to add missing strdup checks to ldconfig?
Index: libexec/ld.so/ldconfig/library.c
===
RCS file: /cvs/src/libexec/ld.so/ldconfig/library.c,v
retrieving revision 1.9
diff -u -p -r1.9 library.c
--- libexec/ld.so/ldconfig/library.c
Hi,
our catopen implementation does not check the parsed message catalog,
making it vulnerable to all sorts of out of boundary accesses.
Take this minimalistic proof of concept file:
$ printf '\xff\x88\xff\x89\x01\x00\x00\x00' > poc.cat
If you are too lazy to write code to open it yourself,
On Sun, Aug 30, 2015 at 12:18:12PM -0600, Theo de Raadt wrote:
In a more complex program with a large main() function, a call to
exit() is an explicit statement about termination, so that even if
someone refactors code to a subfunction, they must consider that
it carefully.
The return is
On Sat, Aug 29, 2015 at 05:02:33PM -0600, Theo de Raadt wrote:
It really does not matter. Coder's choice. The result is the same.
You could hunt them all down, change them all, save a few code bytes,
but don't you dare introduce any bugs...
The main function is called by crt0 like
Hi,
I know this will be the third commit to fix the overflow situation in
getusershell if /etc/shells is malformed. Hopefully it will be the last
adjustment.
I submitted a bug report to glibc devs after noticing that they use the
same implementation like we do (more or less). Paul Pluzhnikov
When creating a new temporary file name, use mkstemp instead of just
taking a rather predictable path, which could even be a symlink by
a malicious user (granted, that is very unlikely).
Index: file.c
===
RCS file:
I see a useless use of cat in here.
Manual page:
When called with the -d option, it must decompress standard input
to standard output.
Index: file.c
===
RCS file: /cvs/src/usr.bin/sort/file.c,v
retrieving revision 1.4
diff -u -p -u
Setting permissions without setting owner and group can have rather
inconvenient results. See this example with latest code:
$ touch test
$ chgrp wheel test
$ chmod g+w test
$ ls -l test
-rw-rw-r-- 1 tobias wheel 0 Mar 31 20:05 test
$ ./sort -o test test
$ ls -l test
-rw-rw-r-- 1 tobias
$ */
+/*
+ * Copyright (c) 2015 Tobias Stoeckmann tob...@openbsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE
On Thu, Mar 26, 2015 at 11:41:23PM +0100, Tobias Stoeckmann wrote:
The less obvious one is in an error path.
As tl-l is always of fixed size (BSZ), we can just change the struct
to have a BSZ sized array in it. This removes the need to do checks
in the error path completely.
While
Hi,
tail -r has two memory leaks when handling non-regular files. You can
easily see memory usage increasing with commands like
$ mknod pipe p
$ tail -r pipe pipe pipe /dev/null
And then writing a large file into the pipe three times. top shows the
memory usage of tail increasing with each
Hi,
grep'ed the tree for siglongjmp calls, and spotted possible offenders in
libssl's code. The code in question checks hardware capabilities for
ARM, S390x, and SPARCv9.
The code will call some routines that could trigger SIGILL (or SIGBUS),
which is caught with an own signal handler. This
Hi,
it is possible to trigger a floating point exception in df when it is
used to retrieve information from a raw device with a broken ext2
file system.
These are steps to prepare a file system with an invalid entry for
e2fs_log_bsize (0xFF):
$ dd if=/dev/zero of=ext2.fs bs=1K count=1440
#
Hi,
this diff adds error handling for funopen() failure. I have also fixed
a whitespace issue for proper intendation.
Tobias
Index: usr.bin/compress/zopen.c
===
RCS file: /cvs/src/usr.bin/compress/zopen.c,v
retrieving revision
Hi,
patch accepts arbitrary ed commands after encountering s. The s
ed command does not expect any further input, which makes it a one line
command like d. Yet, patch sends any lines until . unchecked to ed
through its pipe, allowing command execution.
Example:
$ ls
ed.diff
$ cat ed.diff
0a
On Sat, Dec 13, 2014 at 10:57:42AM -0500, Daniel Dickman wrote:
- (*t == 'a' || *t == 'c' || *t == 'd' || *t == 'i' || *t
== 's')) {
+ strchr(acdis, *t) != NULL) {
doesn't this change the semantics slightly? i haven't looked at the
context beyond
===
RCS file: temp.c
diff -N temp.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ temp.c 13 Dec 2014 19:38:20 -
@@ -0,0 +1,110 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2014 Tobias Stoeckmann tob...@openbsd.org
Hi,
chmod doesn't check if the program name is at least 3 characters long
before checking its index 2.
Also, there is a compiler warning about signed vs unsigned when val
is used. In one instance, it's used with strtoul, in another with strtol,
checking its ranges. It's okay due to automatic
On Fri, Dec 12, 2014 at 10:42:21AM -0800, patrick keshishian wrote:
Just throwing this out there: will this program ever get
installed with filename shorter than ch{grp,mod,own,flags}?
No.
It's still a form of input validation. Therefore, it should be done.
And a user can create such a link
On Thu, Dec 11, 2014 at 08:21:12PM +, Miod Vallat wrote:
Hi,
I'm encountering system crash during boot with latest snapshot. Turns
out that it works fine when I disable skgpio through UKC.
Try this.
Okay tobias@, too. ;)
The system boots nicely again, thanks!
Anyone?
On Sat, Nov 29, 2014 at 05:40:31PM +0100, Tobias Stoeckmann wrote:
Hi,
this diff doesn't just fix the division by zero for input files with
lines longer than 1023 chars in Plan B mode, it actually removes this
line limit!
Before:
$ dd if=/dev/zero bs=1 count=1024 | tr '\0
Hi,
this diff doesn't just fix the division by zero for input files with
lines longer than 1023 chars in Plan B mode, it actually removes this
line limit!
Before:
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' a a
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' b b
$ diff -u a b a.diff
$ patch -x 8
Hi,
the facility number is not properly validated while parsing the
configuration file -- it is possible to supply a number which is
larger than LOG_NFACILITIES, therefore accessing memory outside
of f_pmask's boundaries.
# echo 10.debug;syslog,user.info /var/log/messages my.conf
# syslogd
On Thu, Nov 27, 2014 at 01:29:48PM -0700, Todd C. Miller wrote:
I think it would be better for decode() to just return -1 in this
case.
The validation looks a bit like a magic number there, but this could
prevent issues of other decode()-users, too... So yeah, I think that
is worth it:
Index:
Hi,
turns out that there are a few more bad savestr calls even inside of pch.c.
Some of the code pathes are quite obvious that a NULL return value would
lead to a null pointer dereference, others would last longer before
dereferencing.
Carefully reviewing the savestr calls, the rule of thumb
On Wed, Nov 26, 2014 at 09:48:15PM +0100, Nicolas Bedos wrote:
Last update, with Tobias's help.
The following diff
- changes MAXPATHLEN from sys/param.h to PATH_MAX from limits.h
- adds a missing prototype for sane_count
- locate.bigram and locate.code now abort when reading a pathname
Hi,
it is possible to overflow line numbers in patch; this diff cares about
the lines specified in diff files. If such an overflow happens with
unified diffs, out of bound memory access can occur.
If you have a 32 bit system, take this one (LONG_MAX = 2^31 - 1):
--- a Sat Nov 15 00:25:29 2014
Hi,
patch will fail with a segmentation fault in plan a if it encounters a
diff with a revision (Prereq line) when the input file is empty.
i_womp will be set to NULL to avoid mmapping 0 bytes, but later on it
will be scanned for the supplied revision.
The fix is simple: avoid scanning i_womp
Hi,
the function parallel() should release file descriptors just like
sequential() does: If we reach EOF, close it -- except we were
reading stdin.
Tobias
Index: paste.c
===
RCS file: /cvs/src/usr.bin/paste/paste.c,v
retrieving
On Mon, Nov 24, 2014 at 08:37:47PM +0100, Nicolas Bedos wrote:
In locate.code.c 'mbuf' is never free()d: it is only allocated for the
last line of input and after processing this line the program ends. I
hope it is ok.
I would free() it nontheless outside the while loop. For the sake of
On Sun, Nov 23, 2014 at 06:59:59PM +0100, Nicolas Bedos wrote:
Index: src/usr.bin/locate//code/locate.code.c
===
RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v
retrieving revision 1.17
diff -u -p -u -r1.17 locate.code.c
Hi,
as jsg@ pointed out, rcs will segfault reliably when using malloc.conf with
'J' (the pointer in question is filled with d0's).
The pointer rp_delta is checked at the end of rcsparse_delta. If it's
non-NULL, it will be included into a linked list; line 1181 of rcsparse.c.
This RCS file
On Sat, Nov 22, 2014 at 11:45:02AM +0100, Tobias Stoeckmann wrote:
as jsg@ pointed out, rcs will segfault reliably when using malloc.conf with
'J' (the pointer in question is filled with d0's).
As Theo suggested, xcalloc will take care of this pointer and other
struct entries which
1 - 100 of 154 matches
Mail list logo
