Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
the short write cases.
|
|
PR 2902, Francesco Toscan, Thanks!
|
|
samba wants to create usernames that end in '$'. From Paul Chakravarti
|
|
PR 2891, jlouis at diku dk, Thanks!
|
|
|
|
when altqd is not running.
report and fix by Chad Loder <cloder@loder.us>
|
|
last commit
|
|
- remove FSinfo, we don't install it.
millert pvalchev ok.
|
|
|
|
|
|
o remove trailing spaces for better output.
o print sequence, acknowledge and callid as unsigned, and remove key
from version 1 since it's actually the payload length (not including
the gre header).
jason@ ok.
|
|
|
|
fixes a cross site scripting bug
fixes 2 off-by-ones
|
|
|
|
|
|
|
|
|
|
|
|
least compiles, the name of the file is bogus now (; hin@ ok and promissed to sync it w/ arla repo
|
|
platforms; drahn@ millert@ ok
|
|
adapted from NetBSD. OK markus@ and previously discussed with Theo.
|
|
|
|
- nat rules are no longer in a seperate file, combine nat example
- /32 on all addresses is clutter, since it's the default
|
|
- check explicitly for negative values from snprintf (-pedantic)
- use MAXLOGNAME
- use parentheses with all sizeof's for consistency
|
|
ok millert@ hin@
|
|
ok millert@
|
|
|
|
|
|
Problem found by David Wagner (among others).
|
|
itojun@ ok
|
|
|
|
FreeBSD commit messages say:
Some BIOSs are using MTRR values that are only documented under NDA
to control the mapping of things like the ACPI and APM into memory.
The problem is that starting X changes these values, so if something
was using the bits of BIOS mapped into memory (say ACPI or APM),
then next time they access this memory the machine would hang.
This patch refuse to change MTRR values it doesn't understand,
unless a new "force" option is given. This means X doesn't change
them by accident but someone can override that if they really want
to.
PR: 28418
Tested by: Christopher Masto <chris at netmonger dot net>,
David Bushong <david at bushong dot net>,
Santos <casd at myrealbox dot com>
Make the MTRR code a bit more defensive - this should help people
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).
Here's a description of the problem and my fix:
The problem with the old MTRR code is that it only expects
to find documented values in the bytes of MTRR registers.
To convert the MTRR byte into a FreeBSD "Memory Range Type"
(mrt) it uses the byte value and looks it up in an array.
If the value is not in range then the mrt value ends up
containing random junk.
This isn't an immediate problem. The mrt value is only used
later when rewriting the MTRR registers. When we finally
go to write a value back again, the function i686_mtrrtype()
searches for the junk value and returns -1 when it fails
to find it. This is converted to a byte (0xff) and written
back to the register, causing a GPF as 0xff is an illegal
value for a MTRR byte.
To work around this problem I've added a new mrt flag
MDF_UNKNOWN. We set this when we read a MTRR byte which
we do not understand. If we try to convert a MDF_UNKNOWN
back into a MTRR value, then the new function, i686_mrt2mtrr,
just returns the old value of the MTRR byte. This leaves
the memory range type unchanged.
I have seen one side effect of the fix, which is that ACPI calls
after X has been run seem to hang my machine. As running X would
previously panic the machine, this is still an improvement ;-)
PR: 28418, 25958
Tested by: jkh, Christopher Masto <chris at netmonger dot net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pointed out by nicolas at untz dot net, thanks!
|
|
|
|
not php3.
inspired by a PR from j@pureftpd.org for the -dist file.
|
|
*) SECURITY: CAN-2002-0840 (cve.mitre.org)
Prevent a cross-site scripting vulnerability in the default
error page. The issue could only be exploited if the directive
UseCanonicalName is set to Off and a server is being run at
a domain that allows wildcard DNS. [Matthew Murphy]
|
|
make it work for netbsd/sparc64 (really any sparcv9 running !solaris)
|
|
parameters a bit more logical. missing startssl pointed out by jsyn@, what
made me look at it ;-)
ok deraadt@
|
|
|