This file is already off the vendor branch and there hasn't been a bc
release in more than 4 years so I can't see any harm in fixing this.
Submitted by: Arne Woerner <arne_woerner at yahoo dot com>
PR: gnu/86627
Before (backslash in c syntax meaning):
6 p16-2-0-0.r21.sttlwa01.us.bb.verio.net (129.250.2.180) 71.027 ms \
p16-1-1-3.r20.sttlwa01.us.bb.verio.net (129.250.2.6) 66.730 ms 66.535 ms
7 xe-0-2-0.r20.sttlwa01.us.bb.verio.net (129.250.4.16) 71.092 ms \
xe-3-1.r00.sttlwa01.us.bb.verio.net (129.250.2.205) 66.598 ms \
xe-0-2-0.r20.sttlwa01.us.bb.verio.net (129.250.4.16) 71.024 ms
After:
6 p16-2-0-0.r21.sttlwa01.us.bb.verio.net (129.250.2.180) 71.027 ms
p16-1-1-3.r20.sttlwa01.us.bb.verio.net (129.250.2.6) 66.730 ms 66.535 ms
7 xe-0-2-0.r20.sttlwa01.us.bb.verio.net (129.250.4.16) 71.092 ms
xe-3-1.r00.sttlwa01.us.bb.verio.net (129.250.2.205) 66.598 ms
xe-0-2-0.r20.sttlwa01.us.bb.verio.net (129.250.4.16) 71.024 ms
Submitted by: Richard A Steenbergen <ras at e-gerbil.net>
MFC after: 3 days
researched by glebius, and incorporated by ISC into the next
version of BIND. Unfortunately, it looks like their release
will come after the release of FreeBSD 6, so we will bring
this in now.
The patch addresses a problem with high-load resolvers which
hit memory barriers. Without this patch, running the resolving
name server out of memory would lead to "unpredictable results."
Of course, the canonical answer to this problem is to put more
memory into the system, however that is not always possible, and
the code should be able to handle this situation gracefully in
any case.
(Note this makes the vendor branch not represent Binutils in the vendor's
CVS repository at any point in time. Portmgr did not like the state of
Binutils on Sparc that represented the point in time the vendor fixed this
issue. I'd rather have fixed this on RELENG_6.)
Approved by: re
This allows FreeBSD/PPC to build and run out of stock CVS sources. This
also takes the file off of the vendor branch.
Submitted by: kan, grehan
Approved by: re, kan
The ipfw tables lookup code caches the result of the last query. The
kernel may process multiple packets concurrently, performing several
concurrent table lookups. Due to an insufficient locking, a cached
result can become corrupted that could cause some addresses to be
incorrectly matched against a lookup table.
Submitted by: ru
Reviewed by: csjp, mlaier
Security: CAN-2005-2019
Security: FreeBSD-SA-05:13.ipfw
Correct bzip2 permission race condition vulnerability.
Obtained from: Steve Grubb via RedHat
Security: CAN-2005-0953
Security: FreeBSD-SA-05:14.bzip2
Approved by: obrien
Correct TCP connection stall denial of service vulnerability.
A TCP packets with the SYN flag set is accepted for established
connections, allowing an attacker to overwrite certain TCP options.
Submitted by: Noritoshi Demizu
Reviewed by: andre, Mohan Srinivasan
Security: CAN-2005-2068
Security: FreeBSD-SA-05:15.tcp
Approved by: re (security blanket), cperciva
(1) "ipf -T" is broken for fetching single entries and
(2) loading rules with numbered collections does not order insertion right.
(3) stats aren't accumulated for hash table memory failures
Approved by: re (dwhite)
