Throughout the whole code base only char * is passed, but a unsigned
char * is expected. This leads to several warnings.
Fix the interface and cast to unsigned char * internally to avoid any
changes to the behaviour.
This fixes issue #199 reported by Kuang-che Wu.
A specially crafted Gopher URL (e.g. '<a href=gopher:R>') could lead to
an out-of-bounds read.
Problem here was, that 'p' was incremented twice without checking for
the end of the string.
The interesting question for me is: What does this 'if' actually check?
What is special here about the 'R'? I did not find anything related in
RFC 1436 or in RFC 4266.
This patch fixes issue 200 'heap-buffer-overflow in
shiftAnchorPosition'.
Any input that looks like a tag, but isn't, should just be ignored. HTML
is parsed in a two staged process. Stage 1 inserts internal tags (like
<a hseq=...>). Stage 2 assumes these internal tags are valid input
inserted in the previous stage. If we don't throw away non-valid HTML
tags in stage 1 any website can inject tags that are interpreted as
internal ones. This leads to an out-of-bound read in this test case.
The 'hseq=-90' from the input ends as the value (89 actually) of
'a->hseq' in 'anchor.c:555'. Then 'hl->marks[a->hseq]' is out of bounds
as there are only 30 entries in this list.
This is the test input:
<table>0<br <>0<xmp>È«<div><inteRnal><input_alt fid=0><dl>0<dl>0<button value='">0000000000000000000000000000000000000000ÿ000'><A hseq=-90 href=>0<hR align=middle>
By default, w3m puts all of its data in the `~/.w3m/` directory
(creating it as necessary). This was not configurable in any way.
This commit adds some quick reconfigurability -- when the "W3M_DIR"
environment variable is set, w3m will use that location instead. The
default location is unchanged.
Fixes#130.
Input format
- Less restriction on input length
- Input text and charset no longer overlapped
Performance
- Less memory allocation
- Less disk IO
- Do not force GC. This make the fuzzer roughly 10x faster
ISclose() doesn't free memory if a stream's function pointer, close, is NULL.
However, str_stream's close pointer is always NULL and thus leaks
memory.
This is the same issue as commit 12c7b62a42 and should have been
included there.
'maxcol' can be -1 which results in a size of 0. The array is never
accessed with 'maxcol < 0', but zero length variable length arrays are
undefined behaviour.
Take the correct type from ASN1_STRING_get0_data() to fix a warning.
IA5Strings are ASCII, we do not need to care about signedness.
Since the pointer returned by ASN1_STRING_get0_data() points to internal
memory of the ASN1_STRING we are not allowed to manipulate the data.
Also it is not guaranteed that the data is null terminated. Copy the
data to our own buffer and make sure it is null terminated before using
it.
Compiling with GCC 10.2 with -fsanitize=address,undefined valgrind
and opening the 'opions panel' reports:
table.c:1632:8: runtime error: variable length array bound evaluates to non-positive value 0
table.c:1266:11: runtime error: variable length array bound evaluates to non-positive value 0
table.c:1267:12: runtime error: variable length array bound evaluates to non-positive value 0
'maxcell' is initialized to -1 which results in a size of 0 during the
first iteration. Though the array is only accessed if maxcell >= 0,
using a variable length array with a size < 1 is undefined behaviour
(see e.g. C99 6.7.5.2,p5).
This closes issue #51 .
