Add a sanity check of the disk_buf first three bytes. The original code on
a disk with nul bytes was causing integer overflow and thus calling the
memcmp(3) functin in is_zero() with enormous length.
Verity that the 0th byte is JMP, 1th a signed byte >=9 to prevent overflow
and 2th byte NOP.
Add a comment explaining the check.
Detected with MKSANITIZER and ASan.
cpu_probe_fpu(), and have XEN cpu_init() just act
the xen probe is now guarded by XEN_USE_XSAVE option and XSAVE
support is thus still disabled by default (same as before), so it
wouldn't interfere with maxv's eager fpu rototil, while still
allowing testing for others
PR kern/50332
that is longer than we can handle the same way we treat an unknown
class name (as a valid char class which contains nothing, so never
matches). Previously a "too long" class name invalidated the
class, so [:very-long-name:] would match any of '[' ':' 'v' ...
(note: "very-long-name" is not long enough to trigger this, but you
get the idea!)
However, the name itself has a restricted syntax ([[:***:]] is not a
character class, it is a match for one of a '[' ':' or '*', followed by
a ']') which we did not implement - check the syntax of the name before
treating it as a character class (but we do add '_' to alphanumerics
as legal class name characters).
expansion, case patterrns, etc) do not force '[' to be a member of
every class.
Before this fix, try:
case [ in [[:alpha:]]) echo Huh\?;; esac
XXX pullup-8 (Perhaps -7 as well, though that shell version has
much more relevant bugs than this one.) This bug is not in -6 as
that has no charclass support.
itself, or some other function which is still active.
This was a long known bug (fixed ages ago in the FreeBSD sh) which
hadn't been fixed as in practice, the situation that causes the
problem simply doesn't arise .. ASAN found it in the sh dotcmd
tests which do have this odd "feature" in the way they are written
(but where it never caused a problem, as the tests are so simple
that no mem is ever allocated between when the old version of the
function was deleted, and when it finished executing, so its code
all remained intact, despite having been freed.)
The fix is taken from the FreeBSD sh.
XXX -- pullup-8 (after a while to ensure no other problems arise).
sense and were trying to hide a real bug, which is, that there is for some
reason a wrong stack alignment that causes FXSAVE to fault in
fpuinit_mxcsr_mask. As seen in current-users@ yesterday, rdi % 16 = 8. And
as seen several months ago, as well.
The rest of the changes in XSAVE are wrong too, but I'll let him fix these
ones.
With approval from bouyer@ and acceptance, sometimes grudgingly, from
others I have removed the AGP lines from the XEN3_DOM0 config. I have
left a note in the PR suggesting that if it ever gets a proper fix that
those lines can be considered for re-inclusion.
The path variable is assigned with an allocation on the heap with
strdup(3). Later this pointer is changed with strsep(3) and this caused
invalid free(3).
Store the original pointer in a new helper variable opath and pass it to
free(3). With this change, the problem is going away.
Detected with MKSANITIZER=yes with AddressSanitizer.
so it can be called separately from sata_reset_interface()
do not treat PHY offline as an error, it's pretty normal when there
is no device actually connected
debugging aid for PR kern/52372
