drm/i915/psr: Do not use pipe_src as borders for SU area
From Jouni Hogander
de9aa7e89b98157d2650f25691e40711b8404151 in linux-6.18.y/6.18.23
75519f5df2a9b23f7bf305e12dc9a6e3e65c24b7 in mainline linux
drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat
From Sebastian Brzezinka
2af8b200cae3fdd0e917ecc2753b28bb40c876c1 in linux-6.18.y/6.18.23
4c71fd099513bfa8acab529b626e1f0097b76061 in mainline linux
login_chpass: No longer need to install this setuid root
When the YP code was removed login_chpass became wrapper that just
execs login_lchpass.
OK deraadt@
floating point state leakage can be observed on AMD Zen/Zen+ (Zen 1)
This was discovered by the Rootsec research group at the CISPA Helmholtz
Center for Information Security. Rootsec named the problem
Floating Point Divider State Sampling (FP-DSS).
Do AMD's suggested mitigation, setting a chicken bit in an MSR.
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7053.htmlhttps://roots.ec/blog/fpdss/
ok deraadt@ brynet@
Prevent buffer overflow by checking the correct counter.
An attacker on the same layer 2 network can send rogue router
advertisements, potentially crashing slaacd.
from Maurice Hieronymus (mhi AT mailbox.org), thanks!
from florian@; OK deraadt
this is errata/7.7/039_slaacd.patch.sig
Prevent buffer overflow by checking the correct counter.
An attacker on the same layer 2 network can send rogue router
advertisements, potentially crashing slaacd.
from Maurice Hieronymus (mhi AT mailbox.org), thanks!
from florian@; OK deraadt
this is errata/7.8/033_slaacd.patch.sig
The parking mutex uses data structures on the stack and expects CPUs to be
able to modify that data for other CPUs. Unfortunately on some sparc64
systems (sun4u systems that don't use Fujitsu SPARC64 CPUs) use a trick
where the interrupt stack is mapped using a fixed alias on each CPU. This
means a CPU can only access its own interrupt stack. Fix this by using
the "real" address of the interrupt stack. We still need the fixed alias
though to find our own "struct cpu_info" on these systems. So on
MULTIPROCESSOR kernel we need to use another locked TLB entry.
tested by bluhm@, claudio@, tb@, jca@, dlg@
ok dlg@, jca@
Copy SpacemiT K1 device trees onto the miniroot. With this, installs
should just work on the supported boards. Make sure you install with a
network connection such that fw_update can put the device trees into
your new install as well. Document that "make release" now needs the
riscv64-spacemit-dtb firmware installed.
ok deraadt@, jca@
Don't let malicious or confused scsi tape devices cause reading or writing
outside a mode sense/select buffer.
Original diff from Stanislav Fort of aisle.com with additional paranoia for
negative values.
Tweaks and ok from kettenis@
Revert last commit, rev. 1.446.
The change introduced a regression where sockets get stuck in FIN_WAIT_2
and LAST_ACK.
Noticed by anton@ since regress/sys/net/pflow fails.
Fix vmd(8) vionet reset race leading to broken networking.
A driver reset races with the device asynchronously notifying tx
and rx threads. The current design finishes the reset after the
threads pause and acknowledge the reset. This can clobber device
state because a driver doesn't need to wait before reconfiguring
the device. End result is device thinks it's in a blank slate while
driver thinks device is configured and device refuses to pass packets
thinking the driver isn't ready.
This removes that async reset design and ack message from the
threads. Reset occurs immediately while emulating the write to the
register. A generation counter is used to signal to tx and rx
threads that a reset occurred between they time they finished
processing virtqueues and the time they grabbed the write lock to
change interrupt state on the device so they can safely skip
raising irq lines.
Original bug reports by mbuhl@ and stsp@.
[4 lines not shown]
Attempt to load the right device tree from the riscv64-specmit-dtb
firmware package on SpacemiT K1 boards. The only viable way to do this
seems to be basing this on the "model" property of the root node of
the device tree provided by the device. This is still a bit of a guess
since the Milk-V Jupiter advertises itself as "spacemit k1-x evb board"
and the Banana Pi BPI-F3 seems to say it is a "spacemit k1-x deb1 board".
ok jca@
If you use the floppy, fw_update for some drivers will not work, you will
have to figure out the names of the missing firmwares and request them
manually.
The pci strings in the kernel have become too large, and I'm being told I
may not shorten them.
If you use the floppy, fw_update for some drivers will not work, you will
have to figure out the names of the missing firmwares and request them
manually.
The pci strings in the kernel have become too large, and I'm being told I
may not shorten them.
