Properly bounds check the max_ent check in bsd_decompress().
A specially crafted packet from PPP can trigger a backwards write of
an mbuf of a character, and can cause hangs and crashes as it corrupts
memory in the kernel.
The check against max_ent has an off-by-one error, fixed in this change
and fixes the problem (tested on arm64.)
From Acts1631 via OpenBSD.
XXX: pullup-10, pullup-11
macppc: add MKREPRO support to mkhybrid and fix bugs
1) Fix overlapping strcpy which triggers fortify checks on some hosts
2) Add -timestamp option
2) Don't leak stack garbage into the generated image
PR bin/60496 - fix printf(3) with non-single-byte decimal point & thousands sep
These fixes are relatively simple, and should be safe -- I have had them
in my source tree for ages now.
The fix for the decimal point case is taken more or less directly from
an old FreeBSD fix for the same issue.
The thousands separator case is different - our code and FreeBSD's have
diverged so much in this area that simply using their method would have
been more trouble than it was worth, so I reimplemented it differently
to better fit our code model.
There are ATF tests that go with this, which will be committed one day,
but have been waiting on strfmon(3) fixes, which are related. I decided
these code changes should wait no longer. The tests will come later.
XXX pullup -11 -10
vr(4): reinitialize device when rx engine fails to go to the idle state.
When detecting root via NFS, DHCP timed out on some boots.
Investigation showed that in certain cases RX engine was getting stuck,
likely triggered by an ARP frame arriving before driver handled a link up
state.
NFS boot's RARP fallback was calling media up command, triggering
reinitialization and forced reset, restoring the device state.
Since fallback doesn't set the IP address, NFS boot failed,
requesting to prompt root device again.
Subsequent attempt succeeded since device was reinitialized
by the RARP fallback, but manual input was required.
The fix always verifies successful rx/tx engine shutdown in vr_mii_statchg(),
even when state is active and media link is up.
In case it fails, device reinitialization is initiated, allowing DHCP process
to succeed.
[5 lines not shown]
Add driver for Individual Computers RapidRoad USB controller.
This is a frontend for isp1763hc MI driver.
The controller can either be connected to clockport or local expansion
port on X-Surf 100. For now only clockport connection is supported.
Fix up clockport attachments.
Move bus tag and attach args from the stack into softc. Properly
disestablish interrupt. Handle exactly one device per clockport.
Add driver for ISP1763A USB 2.0 host controller.
It's a relatively simple PIO-driven host/OTG chip, think more modern
and less broken slhci. Only the host part is supported now. Isochornous
transactions are not supported (this is a driver limitation).
Don't try to get the database version from the host's database when running cross.
On hosts like FreeBSD that do have the database in the same place we keep it,
but don't have our explicit version record, this was causing database version 0
instead of 1 to be emitted, which is wrong.
Pull up following revision(s) (requested by riastradh in ticket #1355):
share/mk/bsd.prog.mk: revision 1.360
share/mk/bsd.lib.mk: revision 1.424
share/mk/bsd.prog.mk: revision 1.361
share/mk/bsd.kmodule.mk: revision 1.87
share/mk/bsd.kmodule.mk: revision 1.88
libexec/ld.elf_so/Makefile: revision 1.152
(all via patch)
bsd.prog.mk: Fix parallel builds of debug data.
Previously, we had one rule to generate foo, and another rule to
derive foo.debug from it with objcopy -- and then rewrite foo _in
place_ to strip the debug data with objcopy.
This is wrong -- one rule should never overwrite another rule's
target; this violates the contract with make(1), and can lead it to
run rules in parallel on files that are changing, which in turn can
[39 lines not shown]
Pull up following revision(s) (requested by tls in ticket #516):
tools/Makefile.gnuhost: revision 1.58
build.sh: revision 1.406
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
Pull up following revision(s) (requested by tls in ticket #516):
tools/Makefile.gnuhost: revision 1.58
build.sh: revision 1.406
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
