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
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
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,
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
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
=
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 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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 $
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 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
> ===
>
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 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
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
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
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 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
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
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
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
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
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
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
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
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
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
===
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
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
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
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
.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
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
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
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
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
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(
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. ;)
$ 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
> Comments / oks?
Looks much cleaner, okay for me.
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?
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
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 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
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
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 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);
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
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
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 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
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
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
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.
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 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
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 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
> 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 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
Hi,
Google's Android team uses a modified fsck_msdos version from FreeBSD,
fixing issues in their local repositories. No license adjustments, so we
are free to merge them into ours.
One of these fixes covers an out of boundary access that can occur if
filesystem points to a cluster outside of al
Hi,
our guard pages just told me that writefat is vulnerable to an off by one
for FAT12 filesystems. They shouldn't be that common anymore, but better
be safe than sorry.
The diff looks confusing at first, but this default-block is just split
into two cluster blocks, as it's done in readfat (lin
On Mon, Jun 09, 2014 at 09:16:42PM +0200, Tobias Stoeckmann wrote:
> + cl++;
[...]
> + *p |= (u_char)(fat[cl + 1].next << 4);
> + *p++ = (u_char)(fat[cl + 1].next >> 4);
And here the correct diff, cl + 1 must
Hi,
the howmany macro as used in param.h and select.h is prone to an integer
overflow. It adds divisor-1 to the base value, which means that it
COULD overflow.
Most of the times, the howmany macro is used with file descriptors and
polling, would be hard to overflow it. Especially due to C langu
Hi,
fsck_msdos is prone to an infinite loop if cluster chains in the
filesystem are infinite: FAT handles clusters as linked lists, and at
worst this list can be cyclic.
Android included a fix from Samsung for this issue, with the commit
b6ee08aadb580341a4d80943741b80de16a88b5d:
https://android.
On Sat, Jun 14, 2014 at 11:25:22AM -0400, Kenneth Westerback wrote:
> > /* follow the chain to its end (hopefully) */
> > - for (p = head;
> > + for (len = fat[head].length, p = head;
> > (n = fat[p].next) >= CLUST_FIRST && n <
> > b
Hi,
ran into this problem that NetBSD fixed a few months ago, which
means that this diff is a "NetBSD merge":
Our newfs_msdos creates an invalid FAT32 file system. The "first
free cluster" of FSinfo points to cluster #2, which is used by the
root directory.
Next to that, fsck_msdos is a bit too
Hi,
there is a potential off by one in function fillinusemap() leading to
possible out of boundary access (32 bytes after allocated area).
pmp->pm_inusemap is allocated in msdosfs_vfsops.c like this:
bmapsiz = (pmp->pm_maxcluster + N_INUSEBITS - 1) / N_INUSEBITS;
pmp->pm_inusemap = mallo
On Mon, Jun 16, 2014 at 04:43:02PM -0700, John-Mark Gurney wrote:
> FreeBSD fixed this by increasing the malloc size:
> https://svnweb.freebsd.org/changeset/base/r126086
Which is actually the correct way to do here!
pmp->pm_maxcluster is the largest valid _index_ of pmp->pm_inusemap,
therefore we
Hi,
fsck_msdos checks for linked cluster chains, which means that two chains
cross each other at the same cluster. If 1 links to 3 and 2 links to 3,
the cluster chains starting at 1 and 2 are linked.
This error condition can be fixed during phase 2, either one or both
chains are dropped or the fi
On Wed, Jun 18, 2014 at 08:20:16AM +0200, Alexander Hall wrote:
> >RCS file: /cvs/src/sys/sys/param.h,v
>
> Where else could howmany come from? Can you be sure it's safe to use here?
There are other places where howmany is defined, I can prepare a diff
that will cover all definitions. For now, I
Hi,
while constructing the long file name of a directory entry, it is
possible to access the longName array out of bounds.
Long file names in FAT are supported by additional "long filename"
directory entries. They are kept in reverse (from top to bottom)
with an additional 0x40 flag at the start
On Fri, Jun 20, 2014 at 04:34:19PM +0200, Manuel Giraud wrote:
> + lbuf = NULL;
> + while ((buf = fgetln(fp, &len))) {
> + if (buf[len - 1] == '\n') {
> + if (len == 1)
> + continue;
> + buf[len - 1] = '\0';
>
Hi,
sys/msdosfs is vulnerable to a division by zero when certain FAT
file systems are mounted. This happens due to an overflow of an
unsigned 8 bit value (sectors per cluster).
How to repeat (BEWARE, KERNEL WILL CRASH!!):
# dd if=/dev/zero of=nuke.iso bs=1K count=100
# vnconfig vnd0c nuke.iso
#
Hi,
there should be some more validations in boot.c. Not just to validate
the filesystem, but to make sure that the program won't crash later on
because it assumes some values...
First chunk: The sectors per cluster have to be a power of 2, otherwise
it's possible to send fsck_msdos over the ed
And again...
Could have saved myself time by checking FreeBSD in detail first.
They fixed the issue by adding a simple check:
According to FAT specs, the size of a cluster shall not exceed 64 KB.
That is even a rare case, 32 KB shouldn't be crossed for compatibility
reasons.
Therefore, it's enou
Hi,
time to merge another fix from NetBSD (and FreeBSD who applied it too):
If sector size is not 512, the boot signature is placed at a wrong
position. It always has to be at offset 510/511, not sector size - 2.
# dd if=/dev/zero of=fat.iso bs=1M count=1
# vnconfig vnd0c fat.iso
# newfs_msdos
Hi,
in boot, we have an off-by-one error in readline. When the user ends
input with enter, the string will be ended twice, like:
p[1] = *p = '\0';
Comparing readline with read_conf (reading commands from file),
there is no need to "double end" the input line.
Tobias
Index: cmd.c
Hi,
this is of interest for amd64 and i386 only:
The bootarg code is a code collection to manage a bootarg_list, which
can be assembled into contiguous code with makebootargs().
makebootargs takes two arguments: pointer and available space. Upon
return, the available space variable will be over
Hi,
this diff merges cmd.c files of sys/stand/boot and
sys/arch/zaurus/stand/zboot. Back in time, that file was copied
to add "clear" command for zaurus. Revision 1.2 of zaurus' file added
some clean ups which could be merged back.
Otherwise, get the changes of stand/boot into stand/zboot, too.
On Sun, Jun 29, 2014 at 08:40:53PM +0200, Tobias Stoeckmann wrote:
> Greatly reduces diff-Output between these files: Just "clear" command,
> the same way it was back then.
After feedback from Theo, just kill clear command and therefore use
cmd.c from stand/boot in zboot.
Any za
Hi,
this diff merges NetBSD's revision 1.20 into our tree: There are
some memory leaks in resetDosDirSection.
This is not a simple merge, I have added some things:
- rootDir was not properly freed in NetBSD's commit
(actually it's put into a "free dir entry queue")
- also free memory if root
On Sun, Jun 29, 2014 at 08:40:53PM +0200, Tobias Stoeckmann wrote:
> "cc -c" works for zaurus' cmd.c. I don't have a zaurus, so it would be
> nice if a zaurus owner can test these changes.
Got feedback from zaurus users. The Makefile was missing another change:
It
On Tue, Jul 08, 2014 at 03:01:58PM -0400, Ted Unangst wrote:
> I think it's safe to just have one goto label? free(NULL) is fine.
That's true. If we go into that direction, we can also use the cleanup
function that would be done at the end of directory processing.
Also put two variables static t
Anyone?
On Fri, Jul 04, 2014 at 07:41:07PM +0200, Tobias Stoeckmann wrote:
> On Sun, Jun 29, 2014 at 08:40:53PM +0200, Tobias Stoeckmann wrote:
> > "cc -c" works for zaurus' cmd.c. I don't have a zaurus, so it would be
> > nice if a zaurus owner can test th
1 - 100 of 168 matches
Mail list logo
