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 p
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 mallo
=
RCS file: 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 Stoeckma
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 one
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 freed
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
https://github.com/gwsw/less/commit/e6eb4c8ddd7f4e7135faca
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 do
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 f
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 UI
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 make
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: /cvs/
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: /cvs/
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 sin
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
to
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 922
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 taken
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
6.2-relea
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 read_numbe
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 le
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&m=150091968903042
sorry I didn't intend to ignore your mail. I didn't follow t
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, NetBS
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 -e
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 giv
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 c
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
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 -e vnd0 # create 'a' and set fsize = bsize = 1
# fsck_ff
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 pro
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 h
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 fo
> 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
> +++ gen/getusersh
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 c
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 e
On Fri, Dec 04, 2015 at 04:04:11PM -0800, Philip Guenther wrote:
> [...] For example, if the new code wants to call
> endusershell(), then change PROTO_DEPRECATED(endusershell) to
> PROTO_NORMAL(endusershell) and add a DEF_WEAK(endusershell) in the .c
> file which defines it.
Applied that one, wh
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 newf
On Fri, Dec 04, 2015 at 03:47:07PM -0700, Theo de Raadt wrote:
> > Is it worth it, knowing that it's a deprecated BSD-specific function?
>
> Careful there :-) It isn't deprecated in the BSD's, and it isn't
> deprecated in any other system which is still doing maintainance and
> improvements to it.
Opinions, thoughts?
Joerg Sonnenberger mentioned that getprogname() could be used.
On Sat, Nov 07, 2015 at 12:20:42PM +0100, Tobias Stoeckmann wrote:
> Based on Todd's patch for at and cron, I did a grep through our base
> tree to see if there are more occurrences of self-made
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 submitt
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 spec
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 u_int32_
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 mal
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, ap);
Based on Todd's patch for at and cron, I did a grep through our base
tree to see if there are more occurrences of self-made __progname
handling.
Here's the patch that fixes these cases.
In newfs and newfs_ext2fs, I prevent an out-of-boundary access in case
someone calls them with argv[0] set to a
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 check
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
/us
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 xs
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 memor
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 file
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. ;)
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 (memchr(
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 sug
There are two unchecked mmap calls in ld.so. In ldconfig, I also
added a check to verify that read() retrieved the expected amount
of bytes.
While fixing dl_prebind.c, I noticed that ldconfig also has such a
file. They differ marginally, but there's no reference in Makefile.
Therefore I think the
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 which I
th.c 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
+ *
+ * Permission to use, copy, modify, and distribute this so
.include
Index: 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
+ *
+ * Permission to use, copy, modify, and distrib
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, tha
That's what I get for copy&pasting 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
re
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: /cvs/sr
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 logi
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 me
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, tak
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
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
exit
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 revi
Sent this back in March, so maybe someone wants to review this time? :)
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 thre
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: /cvs/src/usr.bin/so
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 tobia
pfatal("patch file %s not found", filename);
}
- pfp = fopen(filename, "r");
- if (pfp == NULL)
- pfatal("patch file %s not found", filename);
if (fstat(fileno(pfp), &filestat))
pfatal("can't stat %s
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 con
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 signa
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 1.1
pfp = fopen(filename, "r");
- if (pfp == NULL)
- pfatal("patch file %s not found", filename);
if (fstat(fileno(pfp), &filestat))
pfatal("can't stat %s", filename);
p_filesize = filestat.st_size;
@@ -1
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
> contex
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.di
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
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 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!
Hi,
I'm encountering system crash during boot with latest snapshot. Turns
out that it works fine when I disable skgpio through UKC.
Have no serial console on this system so I copied this by typing it down
on my second system... Guess it has the most important parts in it:
[...]
npx0 at isa0 po
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:
&g
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
On Thu, Nov 27, 2014 at 09:52:29PM +0100, Tobias Stoeckmann wrote:
> 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.
>
> I think that is worth it:
Not anymore. There is just
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,
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
# syslog
1 - 100 of 168 matches
Mail list logo