This will affect local messages sent from a different timezone. Also
removed code due to the changed semantics. This was inspired by
Anders Henke from Schlund + Partner AG.
Added boundary check for fscanf() in InitKsyms() and CheckMapVersion()
to prevent an unintended crash when reading an incorrect System.map.
Hello,
I have discovered a potential crash bug in sysklogd. The klogd daemon
doesn't handle really malformed System.map files very well. It has
two fscanf() calls with "%s"format strings that stores to char
sym[512] arrays. This causes a crash if the string field in the
file is longer than that.
Despite being a buffer overflow, this is not a security problem, as
only root can change the System.map file. Nevertheless, I think it
is worth fixing, as the Right Thing for a program should be not to
assume anything about its input and to handle various problems well.
From: Solar Designer <solar@openwall.com>
1. Ensures that "len" is not placed in a register and as such can't be
clobbered by longjmp(). With the particular code, it does not really
matter whether it is clobbered or not, but this avoids the gcc warning.
2. Makes endtty() the signal handler only after the variable that
function uses is initialized. In the original code, the signal
handler was setup too early and if there would be SIGALRM before
control reaches setjmp(), syslogd would segfault (if not worse).
Basically, this is a minor correctness patch.
guaranteed to be available when the child is forked, hence, fixing a
race condition. This used to create problems with UML and fast
machines. Thanks to Jon Burgess <Jon_Burgess@eur.3com.com>
Bug#62358, Bug#71631)
* Upstream: Doesn't re-set log-level if not requested (closes:
Bug#76170, Bug#76170, Bug#85289)
* Upstream: Ignore zero bytes (closes: Bug#85478, Bug#85478, Bug#41068)
* Upstream: Corrected documentation for `-s' (closes: Bug#87020)
* Upstream: test for existence of syslogd-listfiles before calling
them. This got lost due to 1.4.0 brokennes which was packaged and
removed some hours later (closes: Bug#84872, Bug#66712)
* Applied patch by Tommi Virtanen <tv@debian.org> splitting the package
into `sysklogd' and `klogd' (closes:Bug#35586, Bug#72043, Bug#74864,
Bug#72122)
* Provide / depend on virtual packages system-log-daemon
and linux-kernel-log-daemon (closes: Bug#67604)
* Applied patch from Tim Janik <timj@gtk.org> to support `-s pattern' in
syslogd-listfiles
* Transition to FHS, i.e. /usr/share/doc instead of /usr/doc and
/usr/share/man instead of /usr/man (closes: Bug#79250, Bug#80771)
* Use --exec for stopping services (closes: Bug#76757)
* Corrected broken character in klogd.8 (cloes: Bug#75932)
* Only rotate logfiles with size greater than zero. This got lost due
to 1.4.0 brokennes which was packaged and removed some hours later
(closes: Bug#74993, Bug#49824)
* Added another note about modificability of cronjobs (closes:
Bug#88741)
* Since klogd replaces parts of sysklogd a proper Replaces line is there
* Added final newline to CHANGES
. Changed SOCK_STREAM to SOCK_DGRAM in syslog.c
. klogd will only change the console log level if `-c' is supplied
. syslogd.c by Bill Nottingham <notting@redhat.com>
Um, if the directory is invalid, the bind() call in
create_unix_socket fails. Without the return -1, we return the
invalid fd that we just closed. When syslogd then starts
listening, select goes into a hard loop getting EBADF, IIRC.
. klogd.c by Troels Walsted Hansen <troels@thule.no>
I found a bug in the sysklogd package version 1.4. When it
encounters a zero byte in the kernel logging output, the text
parser enters a busy loop. I came upon it when the 3c59x driver
from kernel 2.4.0 started outputting two zero bytes for the product
code of my laptop's 3Com card. It could be argued that the kernel
should never output zero bytes in the logging info, but obviously
that will happen from time to time.
I fear this bug might be considered a security issue as well, if
the kernel can be coerced to output a zero byte somehow, all kernel
logging will stop.
Wolfgang Oertl <Wolfgang.Oertl@uibk.ac.at> had a similar bugfix
idea
. klogd.c by Thomas Roessler <roessler@does-not-exist.org>
Additionally, the patch prevents LogLine from being invoked with a
negative counter as an argument.
. klogd.c by Troels Walsted Hansen <troels@thule.no>
I found a bug in the sysklogd package version 1.4. When it
encounters a zero byte in the kernel logging output, the text
parser enters a busy loop. I came upon it when the 3c59x driver
from kernel 2.4.0 started outputting two zero bytes for the product
code of my laptop's 3Com card. It could be argued that the kernel
should never output zero bytes in the logging info, but obviously
that will happen from time to time.
I fear this bug might be considered a security issue as well, if
the kernel can be coerced to output a zero byte somehow, all kernel
logging will stop.
Wolfgang Oertl <Wolfgang.Oertl@uibk.ac.at> had a similar bugfix
idea
. klogd.c by Thomas Roessler <roessler@does-not-exist.org>
Additionally, the patch prevents LogLine from being invoked with a
negative counter as an argument.
Removed unixm/unix domain sockets and switch to Datagram Unix
Sockets. This should remove one possibility to play DoS with
syslogd. Thanks to Olaf Kirch <okir@caldera.de> for the patch.
into "%s". Thanks to Solar Designer <solar@false.com> for the patch.
This refers to CVE-2000-0867
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0867
Kernel logging daemon (klogd) in Linux does not properly cleanse
user-injected format strings, which allows local users to gain root
privileges by triggering malformed kernel messages.
Except, users cannot insert arbitrary strings in the kernel log
rinbuffer, can they?
