Add device tree bindings for the MediaTek MT7628 embedded Ethernet
Switch.
The Switch provides 5 external user ports and 1 internal CPU port, with
integrated 10/100 PHYs and fixed port to PHY mapping.
The CPU port is internally connected and uses port index 6.
Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260813190241.789323-2-joey@tinyisr.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
fuse_get_req() parks background allocations on fch->blocked_waitq via
wait_event_state_exclusive(), so each wakeup releases exactly one
waiter. fuse_chan_max_background_set() clears fch->blocked when the
new limit exceeds num_background, but the accompanying wake_up()
releases a single waiter regardless of how many slots just became
available. Raising max_background from 10 to 100 therefore admits one
request instead of ninety.
The remaining waiters are not permanently stranded — the "else if
(!fch->blocked)" branch in fuse_request_end() wakes one more per
completion — but that only helps while requests keep completing.
Consider a fixed pool of threads doing readahead or async direct I/O
with the quota exhausted: every thread is either in flight or parked,
and each completion wakes one waiter while freeing one slot, a net
change of zero. num_background oscillates around the old limit and
the added quota is never taken up.
Waking one waiter per freed slot also preserves submission order:
once fch->blocked is clear, new callers of fuse_get_req() skip the
waitqueue entirely, overtaking waiters that parked before the limit
was raised.
Use wake_up_nr() with the number of slots that just became available.
Since the wakeup is guarded by !fch->blocked, num_background is
strictly below max_background, so the count is at least 1 and never
degenerates into wake_up_all().
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-By: Horst Birthelmer <hbirthelmer@ddn.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Jonas Jelonek says:
====================
net: pse-pd: add Realtek PSE MCU support
This series adds a PSE-PD driver for the microcontroller (MCU) that
fronts the PSE silicon on a range of managed switches, together with its
DT binding.
Hardware model
==============
These boards do not expose the PSE chips to the host directly. A small
microcontroller sits on an I2C/SMBus or UART bus and manages one or more
PSE chips behind it; the host CPU only ever talks to that MCU, using a
fixed 12-byte request/response protocol with a trailing checksum. The
PSE silicon never appears on the bus.
Two generations of the protocol exist, both Realtek's: an older one on
boards with Broadcom PSE silicon (BCM59111, BCM59121) and a newer one
used with Realtek's own PSE silicon (RTL8238B, RTL8239, RTL8239C). They
diverge in opcode numbering and a few response layouts; the driver
abstracts that behind a per-dialect opcode table and parser hooks,
selected by the compatible. The specific PSE chip behind the MCU is
detected at runtime and only influences per-chip constants (power scaling
and the per-port cap).
The compatibles
===============
The protocol compatibles name two generations of the Realtek protocol,
with the I2C framing folded in:
realtek,pse-mcu-gen1 gen1, UART
realtek,pse-mcu-gen1-smbus gen1, I2C/SMBus
realtek,pse-mcu-gen2 gen2, UART
realtek,pse-mcu-gen2-smbus gen2, I2C/SMBus
realtek,pse-mcu-gen2-i2c gen2, raw I2C
and each board carries a device-specific compatible that falls back to one
of these, e.g.
compatible = "zyxel,xs1930-12hp-pse", "realtek,pse-mcu-gen2-smbus";
The naming is the part most likely to raise questions, so the reasoning up
front (the binding documents it too):
- The node describes the MCU together with its Realtek firmware, not a
PSE chip and not the microcontroller silicon. The PSE chips sit behind
the MCU, never appear on the bus, and are reported by the MCU and
detected at runtime; the microcontroller itself is a general-purpose
part (GigaDevice, Nuvoton, ...) that varies across boards. What is
fixed and Realtek's is the firmware and its host protocol - hence the
'realtek' prefix.
- gen1 and gen2 are two generations of that protocol, both Realtek's:
gen1 on older boards fronting Broadcom PSE silicon, gen2 the altered
protocol used once Realtek shipped their own PSE silicon. The
generation is fixed per board and is all the driver needs at DT-parse
time, so the compatible encodes it.
- On I2C the MCU firmware expects one of two framings - SMBus or raw
I2C - which is a genuine programming-model difference, so it is part
of the compatible ('-smbus' / '-i2c'). A UART attachment carries no
framing suffix; the transport is given structurally by the parent
'serial' node.
- Each board additionally carries a device-specific compatible that
falls back to the protocol one. The driver only ever binds on the
protocol compatible; the device-specific string keeps the binding
specific and reserves a place for a future per-board quirk without
having to retrofit device trees already deployed in the field.
Testing
=======
- Linksys LGS328MPCv2 (RTL8238B, I2C)
- Zyxel GS1900-10HP A1 (BCM59121, UART)
- Zyxel GS1900-10HP B1 (RTL8238B, UART)
- Zyxel GS1920-24HPv2 (BCM59121, SMBus)
- Zyxel XMG1915-10EP (RTL8239C, UART)
- Zyxel XS1930-12HP (RTL8239, SMBus)
====================
Link: https://patch.msgid.link/20260813222036.873930-1-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the serdev (UART) transport for the Realtek PSE MCU core. It registers
the MCU as a serdev device and provides the send/recv callbacks the core
uses to exchange the 12-byte frames, receiving asynchronously via the
serdev receive_buf callback.
The baud rate defaults to 19200 and can be overridden per board with the
"current-speed" property.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20260813222036.873930-5-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the I2C/SMBus transport for the Realtek PSE MCU core. It registers
the MCU on an I2C bus and provides the send/recv callbacks the core
uses to exchange the 12-byte frames.
The MCU firmware expects one of two framings on the I2C bus, and which one
is part of the compatible: '-smbus' (reads carry a leading command byte
and a repeated start) or raw '-i2c' (bare block writes and reads). The
match data flags the raw-I2C case; SMBus is the default because that's
what the majority of devices uses.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20260813222036.873930-4-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
A range of managed Realtek-based PoE switches use a small microcontroller
on the PCB to front the actual PSE silicon. The host CPU talks to that
MCU over I2C/SMBus or UART using a fixed 12-byte request/response
protocol with a trailing checksum; the PSE chips are managed by the MCU
and are not accessed directly. Two generations of the protocol exist -
both Realtek's - diverging in opcode numbering and a few response
layouts; the driver handles this with a per-dialect opcode table and
parser hooks for the responses that differ, selected by the compatible.
The specific PSE chip behind the MCU is detected at runtime and only
influences per-chip constants (power scaling and the per-port cap).
This core module implements the protocol, message framing, the dialect
machinery and the pse_controller_ops glue, and exports a registration
helper for transport modules. The I2C and UART transports that drive it
follow in the next patches; the core (PSE_REALTEK_MCU) is selected
automatically by those transports and is not user-selectable on its own.
The realtek-pse-mcu-* files and PSE_REALTEK_MCU* symbols match the
realtek,pse-mcu-* compatibles (see the binding for the naming rationale).
The two protocol generations - gen1 on older Broadcom-PSE boards, gen2 on
Realtek's own PSE silicon - are both Realtek's, handled by the same shared
core, each selecting its dialect via the compatible.
Power budgeting is left to the MCU firmware; the driver advertises
PSE_BUDGET_EVAL_STRAT_DYNAMIC accordingly.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://patch.msgid.link/20260813222036.873930-3-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a binding for the microcontroller (MCU) that fronts the PSE silicon
on a range of managed Realtek-based switches. The host talks only to the
MCU, over I2C/SMBus or UART, using a fixed message-based protocol; the
PSE chips behind it never appear on the bus.
The device is the MCU together with its Realtek firmware: the firmware
and its host protocol are what the binding describes, not the
general-purpose microcontroller they run on. The PSE silicon behind the
MCU (Realtek or Broadcom) is reported by the MCU and detected at runtime,
so it is not described here - hence the 'realtek' vendor prefix.
Two protocol generations exist, both Realtek's, selected by the
compatible: gen1 on older boards (fronting Broadcom PSE silicon) and gen2,
the altered protocol used with Realtek's own PSE silicon. On an I2C
attachment the framing the MCU firmware expects is part of the compatible
as well - '-smbus' or raw '-i2c'; a UART attachment carries no framing
suffix, as the transport is given by the parent serial node.
Each board additionally carries a device-specific compatible that falls
back to one of the protocol compatibles above. Drivers bind on the
protocol compatible; the device-specific string identifies the board and
reserves a place for a future per-board quirk without having to retrofit
device trees already in the field.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20260813222036.873930-2-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Nguyen Dinh Phi says:
====================
vsock: fix stale sk_err handling after a failed connect
A socket whose connect() failed keeps sk_err set. If that socket is
later reused as a listener, vsock_accept() rejects an unrelated
incoming connection, and on virtio/hyperv the resulting child socket
is leaked.
Patch 1 removes the listener's sk_err check from vsock_accept(), since
no vsock transport ever sets sk_err on a TCP_LISTEN socket. This will
fix what the syzbot reported.
Patch 2 removes vsock_sock.rejected, now unreachable after patch 1.
Patch 3 is a related but separate fix: vsock_connect() now consumes
sk_err via sock_error() once it has been returned to userspace, so a
failed blocking connect() doesn't keep reporting the same error a
second time.
====================
Link: https://patch.msgid.link/20260813173024.2362935-1-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
vsock_connect() returns sk_err to userspace but does not clear it:
if (sk->sk_err) {
err = -sk->sk_err;
For a blocking connect() the error has already been delivered as
connect()'s return value, so leaving it set causes subsequent operations
like poll()/epoll() to keep reporting POLLERR even though the connect
failure was already delivered.
The error should be consumed once it has been returned to userspace.
Switch to sock_error(), which reads and clears sk_err atomically,
matching the behavior of other protocol implementations such as
__inet_stream_connect().
Fixes: d021c34405 ("VSOCK: Introduce VM Sockets")
Tested-by: Wupeng Ma <mawupeng1@huawei.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Link: https://patch.msgid.link/20260813173024.2362935-4-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
After previous patch, the branch marking a socket rejected in
vsock_accept() is unreachable, and nothing ever sets vsk->rejected
elsewhere.
In fact, since commit d021c34405 ("VSOCK: Introduce VM Sockets"),
where `rejected` was introduced, there has never been a path that sets
sk_err on a listening socket, so that branch has been dead code since
the beginning.
Therefore, we can remove the `rejected` field from vsock_sock structure.
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260813173024.2362935-3-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Syzbot reported an issue which can be reproduced with these steps:
r0 = socket(AF_VSOCK, SOCK_STREAM, 0)
bind(r0, {VMADDR_CID_ANY, PORT})
connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect)
listen(r0, backlog) -> 0
r1 = socket(AF_VSOCK, SOCK_STREAM, 0)
connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
accept(r0) -> -1, EPROTO (stale sk_err)
Basically, it creates a socket (r0) and triggers a self-connect after
binding it. This self-connect fails with EPROTO because it loops back
to r0 while the socket is still in the TCP_SYN_SENT state, causing it
to be incorrectly dispatched to the connecting-client path. The
unexpected packet type encountered there sets sk_err to EPROTO.
After that, it invokes a listen() call on the same socket. This
listen() call succeeds because the kernel's listening path never
inspects or clears sk_err. Then, a new socket (r1) is created as a
normal client and connects to r0. However, vsock_accept() rejects this
incoming connection because the listener's sk_err still holds the
EPROTO error from the earlier failed self-connect.
This rejection causes the child socket created for r1's connection to
never be freed on virtio or hyperv transports; only the VMCI transport
implements pending_work to revisit and clean up a rejected socket.
For a non-blocking connect(), vsock_connect() may return -EINPROGRESS
immediately, and vsock_connect_timeout() can later set sk->sk_err
asynchronously.
Since no vsock transport ever sets sk_err on a socket while it is in
TCP_LISTEN state, checking it in vsock_accept() serves no purpose and
only carries forward errors left behind by earlier, unrelated
connection attempts on the same socket. Remove the checks so accept()
no longer rejects valid incoming connections because of a stale
error, which also avoids the resource leak described above.
Fixes: d021c34405 ("VSOCK: Introduce VM Sockets")
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Suggested-by: Michal Luczaj <mhal@rbox.co>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260813173024.2362935-2-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
fuse_init_server_timeout() limits timeout to fuse_max_req_timeout with
the same logic as min_not_zero(), and returns early exactly when the
computed timeout would be zero.
So use min_not_zero() instead and return when the computed timeout is
zero.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
The users which rely on regmap IRQ to create the IRQ chip may also
want to have an additional tracking of the IRQ requests and releases.
Provide a callback for them.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmpH1IMACgkQJNaLcl1U
h9BbqQf+Kbxx8fZTq9/B2We7wNK70hyrMB1hsnyKRGSgJXBEr+V/k5C5iG+vzFjB
syZLwk+Ghkk+FvtQbZsBrtkbY0kPyUz0xff+X6VyJO5ylFQs27RijTPwI1MheU+o
baSOhwRaAs8FFJdBEdC611STaxYVuJKc2Z+fKPQGp54VpD0anXjgTFTe0SP6IrnT
H7HtbQUIP3ZTtCLH2/Fq9ZZfeCmpOkeuvr5iMv/KrSI5uv6AkB8eCoTt1gnTSnNh
3XDkTlhT2EnoEEc2TCFi392rUcu+sv5sbld6PwaXlhJryLYz+95IXEWFYYwDL64c
3t0ElJvBRZIoOc9Ry589ElXxPbEQFQ==
=d+FT
-----END PGP SIGNATURE-----
Merge tag 'regmap-irq-reqrel' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into gpio/for-next
regmap-irq: Provide IRQ resource request and release callbacks
The users which rely on regmap IRQ to create the IRQ chip may also
want to have an additional tracking of the IRQ requests and releases.
Provide a callback for them.
drivers (Daniel Lezcano)
- Fix missed file when manually applying a change after a conflict
resolution for the QCom SPMI ADC TM5 Gen3 (Daniel Lezcano)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGn3N4YVz0WNVyHskqDIjiipP6E8FAmqEPbgACgkQqDIjiipP
6E/CCwf8CYdcQxtZDGpzIwe6q75s7l6arupX1Rn74xAypkaAc9gWD9pbmhJoEYXe
LIO/jZDxTYjZCnixnvT1F4UYRfMRvxpLirilW1Yoq2fvgn22DH6xePUbXtAvEVoY
v2MztQ1gaROLrsvvXtul03EWUGuDe+8HWOPUP379FIzMyga+2BrOuz9UXcO/Qvov
6DGyi+WBngAgJGsxpkdGCAaUS0EiJk+9CQ00qxvMhY01RYwtSW0jD+Nr7vXZ7Uzn
crhIYXf4ciXFFfYL9N1E0kjcp6/oCEyN1gITRnbnySBiarDXAV9sGWhyAIrNcPmb
7jCe6GDbd31s9a04wbPNfxwTozlEjg==
=mu9/
-----END PGP SIGNATURE-----
Merge tag 'thermal-v7.3-rc1-fixes' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux
Pull thermal driver fixes for 7.3-rc1 from Daniel Lezcano:
"- Fix missing bitfield include headers in Armada and QCom SPM BMG
drivers (Daniel Lezcano)
- Fix missed file when manually applying a change after a conflict
resolution for the QCom SPMI ADC TM5 Gen3 (Daniel Lezcano)"
* tag 'thermal-v7.3-rc1-fixes' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux:
thermal/drivers/armada: Fix missing bitfields include
thermal/drivers/qcom/spm mbg tm: Fix missing bitfield header
thermal/drivers/qcom: Fix missing spmi adc tm5 gen3 file
validate_password_input() computes length = strlen(buf) and then
checks buf[length - 1] to strip a trailing newline, without checking
that length is nonzero first. Writing an empty string (a bare '\n')
to current_password or new_password gives length == 0, and
buf[length - 1] reads buf[-1], one byte before the heap allocation
holding the copied input.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
Read of size 1 at addr ffff88811bd8da9f by task sh/13740
...
store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
current_password_store+0x14/0x20 [hp_bioscfg]
...
The buggy address is located 23 bytes to the right of
allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88)
Reproduced identically via new_password_store. Execution continues
past the bad read (the garbage byte only affects whether "length" is
decremented by one), so the write completes and returns success; this
is a pure information read past the buffer, not a crash, but it is
still an out-of-bounds access KASAN correctly flags.
Fix by only checking buf[length - 1] when length is nonzero.
Fixes: 8646a3b5ee ("platform/x86: hp-bioscfg: passwdobj-attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260812111829.172273-4-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
sk_store() and kek_store() strip a trailing newline from the sysfs
write before allocating the key buffer:
length = count;
if (buf[length - 1] == '\n')
length--;
bioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL);
but then pass the original "count" (not "length") as the copy size to
hp_wmi_perform_query(), which memcpy()s that many bytes out of the
"length"-sized allocation, reading one byte past it whenever the write
ends in a newline, the normal case for a shell "echo" into sysfs.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg]
Read of size 28 at addr ffff88813c8e2b80 by task python3/16022
...
sk_store+0xa7/0x240 [hp_bioscfg]
kernfs_fop_write_iter+0x3e1/0x5d0
...
The buggy address is located 0 bytes inside of
allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b)
Reproduced identically for kek_store, and at multiple write sizes
(28, 57, 201 bytes), each time reading exactly one byte past a
kmemdup() allocation one byte smaller than the write.
Fix by passing "length" instead of "count" to hp_wmi_perform_query()
in both functions.
Fixes: b2715aa2e1 ("platform/x86: hp-bioscfg: spmobj-attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260812111829.172273-3-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
hp_get_string_from_buffer() clamps the converted string length against
the destination buffer size with "size > dst_size", so when the
converted length is exactly equal to dst_size, conv_dst_size is left
at dst_size and the unconditional NUL terminator write
dst[conv_dst_size] = 0;
lands one byte past the destination buffer. This is the same shape of
bug as the previously fixed off-by-one in hp_convert_hexstr_to_str():
the buffer is sized correctly for the content, but the terminator
write is never checked against that size.
Fix by changing the comparison to ">=" so conv_dst_size is always left
with room for the terminator.
All fixed-size destinations that reach this function (path[512],
current_value[512], current_password/current_value[64], and the
per-entry buffers in encodings[][512] and prerequisites[][512]) are
affected.
Fixes: a34fc329b1 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260812111829.172273-2-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The fuse-io-uring transport copies req->in.h out to the ring in
fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit().
Both headers live inside the fuse_request slab object, whose cache
(fuse_req_cachep) is created without a usercopy whitelist, so copying
them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and
panics:
usercopy: Kernel memory exposure attempt detected from SLUB object
'fuse_request' (offset 56, size 40)!
kernel BUG at mm/usercopy.c:102!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:usercopy_abort (mm/usercopy.c:90)
Call Trace:
__check_heap_object (mm/slub.c:8268)
__check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223)
copy_header_to_ring (fs/fuse/dev_uring.c:618)
fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785)
fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306)
tctx_task_work_run (io_uring/tw.c:96)
task_work_run (kernel/task_work.c:233)
io_run_task_work (io_uring/tw.h:84)
io_cqring_wait (io_uring/wait.c:278)
__do_sys_io_uring_enter (io_uring/io_uring.c:2685)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Bounce both headers through an on-stack copy so the usercopy touches
stack memory, not the slab object.
Fixes: c090c8abae ("fuse: Add io-uring sqe commit and fetch support")
Cc: stable@vger.kernel.org
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Bernd Schubert <bernd@bsbernd.com>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
- Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs.
- Harden the SNP and TDX "populate" ioctls against bad input, and to prepare
for supporting in-place private<=>shared conversion.
- Fix a variety of #DB priority bugs.
- Fix a class of races related to enabling Hyper-V emulation on a vCPU after
the vCPU is visible to the rest of KVM.
- Use static calls for nested virtualization ops.
- Move more KVM-internal code out of x86's kvm_host.h.
- Enumerate support for a variety of Zhaoxin instructions that don't require
explicit virtualization.
- Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path.
- Harden kvm_vcpu_map() against double-mapping and thus leaking references.
- Misc fixes and cleanups, e.g. for largely benign syzkaller splats.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp8uZQACgkQOlYIJqCj
N/2Pgw//ZmY9QZSvbSS69yYporgRhlTCMq1k3siLYfT19XShCpjO0KK9QTggs57L
0JXgbv4kwzvWWliwlRVK3e2nw027GI0j0kDRdcI3RAsaufZCjVT300cfUJBy/T4C
EQLULA8J3Q5pXStuW7SS2bMjI/D6J0+h80co1gfN4yeBDuKXUhtpmW9G/frCQyqI
3DduI57IBWO+pHImMWVx5jFc6WeDokQPxVASWE4zAU5PobXZSQ2K7KCbcx/rHxLt
3JZRw9sECF4Rn5DHm9Xag4bfZH0IR1jQ4P5fIzlvvYcW8yhj4CcTK648fVivBCL5
cpVQRCUVM6DyAX7l6tchP44XHv8a+D/bB2qZUlKvrMiSYA3usW7olKEDNUPI0dsm
vviat3br/XBu3msNkMZcYoP2WS+ka9zDAkSw7MkNWg1m62UfzvI70AQC0r7Fs/UG
+bUwMpJ11C/TOjwVL8DNMu0RT2uPgZ2xgtyD/IeVrqlm867xtlGxit+Uqs9V0vro
LC2YhNR2LYk8NhKO/IZsHI/9eTD4xQyPBn13U6dsZy19fqcPftSJM7avZfQNiA+l
nPN3v/FZmM22k32hc4NmGCx1/pBU1QtnTcZ0Z91pVzD5+DrvpYnMJpdhazrLL18j
IN2OK+Vy/WiP2xnAvCjOFcHCVgAe3SCorqIrjRlY2nMbnRmc03E=
=bQJe
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-misc-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM x86 misc changes for 7.3
- Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs.
- Harden the SNP and TDX "populate" ioctls against bad input, and to prepare
for supporting in-place private<=>shared conversion.
- Fix a variety of #DB priority bugs.
- Fix a class of races related to enabling Hyper-V emulation on a vCPU after
the vCPU is visible to the rest of KVM.
- Use static calls for nested virtualization ops.
- Move more KVM-internal code out of x86's kvm_host.h.
- Enumerate support for a variety of Zhaoxin instructions that don't require
explicit virtualization.
- Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path.
- Harden kvm_vcpu_map() against double-mapping and thus leaking references.
- Misc fixes and cleanups, e.g. for largely benign syzkaller splats.
- Remove a dying VM from the GA Log notifier list before the VM is actually
destroyed, to fix a potential use-after-free.
- Don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when
pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory
introduced by KVM's (correct) usage of long-term pins.
- Allocate full pages for SEV/SEV-ES {DE,EN}CRYPT ops on SNP-enabled hosts to
fix a data corruption issue due to the PSP driver assigning to-be-written
pages to firmware (as required by the SNP specs).
- Unconditionally intercept ICBEP so that KVM generates the correct guest RIP
when handling an ICEBP-induced TASK_SWITCH #VMEXIT.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp80WUACgkQOlYIJqCj
N/3JuhAAv0zwXVVCQbE8Ni3CT/Wl03MEXGDsqlv1mBbsI5WkOte4CshCK8oHAYs4
LDhO6Y4BlIRJ78itpzk+FF5pvx0MPLi535PNx71o2IGKRZ2T/0u9GVFvHjXdM61F
OdMFSbRYTg4EHPhqskYN4vIy11Qd3vhaklwcDXxnxlZeTq2wtuVwa1GM7rkmiyRs
w3dtNrjSTM2axc4+H+gIN/WN5wM5jxsMVxhPdhPzK2isl4+btD9PG7BG64+aZVqJ
qW9CVTEz81yXdR04sTYutV0Hf56TzGE1RC75MH5nMi7AT9Lfq9L8eVSqPpCZBG/z
YTO8oSQtD9SrIabE8YQ/pBf+LH4DpDCnxjA5IDeiP/6BW54Via6PXpDQQGGrgqWF
pWs2jlc1nUxlrUPrPsQxx1yiFk0xDb/ketgwCHvVilyT5CV33ZO3w995FA3Lvjgy
KY12jxl1jwb8SgZfEkVhUQBNSIsfhj6Wb+jJdbvgcA5M7iUbKk7bBGaokhTbGsev
e63JCVFRydidINyk+LsvUfgjm1ua18x97A7ihcNMIsJY9CCALK8B/HtyPena2phM
F+EZ+IydI/JIrXU4C/o0tWm+mlKbGsxAoCcVx/OkIsckEQYhBgcYPlKr5hZvzy1S
deEmOEXB9cUIO11AOELYnRwEJl6xNuxa226It7WUtmuYQ9t5z48=
=MkIK
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-svm-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM SVM changes for 7.3
- Remove a dying VM from the GA Log notifier list before the VM is actually
destroyed, to fix a potential use-after-free.
- Don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when
pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory
introduced by KVM's (correct) usage of long-term pins.
[This is correct because, while FOLL_WRITE was needed in the past to trigger
CoW unsharing, nowadays FOLL_LONGTERM does that already even without
FOLL_WRITE. And in fact, get_user_pages() actually disallows FOLL_WRITE
together with FOLL_LONGTERM. This change was acked by the MM maintainers.
For more inforamtion see commit ee1a586dd1.
- Paolo]
- Allocate full pages for SEV/SEV-ES {DE,EN}CRYPT ops on SNP-enabled hosts to
fix a data corruption issue due to the PSP driver assigning to-be-written
pages to firmware (as required by the SNP specs).
- Unconditionally intercept ICBEP so that KVM generates the correct guest RIP
when handling an ICEBP-induced TASK_SWITCH #VMEXIT.
- Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM
could miss a TLB on a future, successful VM-Enter with the same L2 VPID.
- Cap the maximum value shoved into the VMX Preemption Timer to workaround an
erratum that affects all existing Intel CPUs that support CPUID 0x15.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp82CwACgkQOlYIJqCj
N/1ekg//Z3ulUOnxKhywPtJ9T2bGlGoqJwslTygFy2JQfR4eNdnNYvtLU2A6Gsa2
1IaB/xJqMtSb+XxpgghYuGvU29J/i25QOJRM0RyJhaXxYvDkZPP4P1gwm9/qniFn
OTITTM37twD98uIYMjOXP6UsK7MPg2Kogv74hYwTpHVj/ti9weLwRX+x+bmlA2Aj
lPFUqPqQkLWFvhoSLV5uYW1rZfLtq/UdlV13DCF+vtp1u6IXaW6mFG5RMFog9kSt
arIW2ZG9Gx7SwrLrpRUSpQyRZugzTcNyl/lK+/sGzONfJO1Gw2QZ7bJFckhXoRt1
ktR5ZAXc8Zy7It7gsNozvQD1NsnT2+FTDzygv7h15IIOwWi+quWF63BCNz+in5RA
ivmFrUnRwmbGgoshpD+JjwR5qW7TK0lOLudWMWnH6ctIH3PvgJrNiIuTbKNGxtkI
D0WuDLrLcSqiR9M8q5eLTKiRjykYugG81KIHIMoTBszpO8/qIhdXyPUr3TPUkoHR
SeDL0m4KdURZR2cOTOvy6DIPTY2qn+rpxRFkqXJCUx/98kajsF0/0RDMBwUeaGF8
Y9e9bgR7YW8hMd6z64ODFTLUSMYXavC0AJpQq3spWg0bo15CcAFTAAnyAQOpTgyo
IGENMWREkCa62RrveZLhN3rFkYBbGMZSuBa0UQM+NvvJXDwdJ90=
=BvM6
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-vmx-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM VMX changes for 7.3
- Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM
could miss a TLB on a future, successful VM-Enter with the same L2 VPID.
- Cap the maximum value shoved into the VMX Preemption Timer to workaround an
erratum that affects all existing Intel CPUs that support CPUID 0x15.
The last user of this function was the recently removed vport-gre
module from openvswitch. Let's drop the function. All other modules
use the strict variant.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260815001942.1089545-1-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
- Fix a bug where KVM would walk a newly created rmap without holding the rmap
lock (or mmu_lock) during aging.
- Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp8wS8ACgkQOlYIJqCj
N/2SmQ//ecBzKzw5uQVwigrVGwWNZS1I00d4DZsYQpD/cAfSuKCYG4YGfG5IBtUy
tvMmoPswmTbullysJxB2bW0JOPjmGGEE6lsNhCH7CmgpKXdeBgqUo2x+KHVV8hFv
YlXXBA2rkbtObMjQgfaByIjv2M3d0trSkOfe39WvPEcfqjOBp3GK22km9eHw4qN2
PqidjSHtAzwcsd+id1cmw5uoel9RKOpux7FPM5mfVIWHJByDrY5sUU+u9Ug0p4F1
2wWbG6ghdnO0LsFFrGD2K2Ummux1KaBuFny/q4cqv3dg3IsMrLcX5xpmC9Z+N1Ey
mmq0D87VXzxEaYXDiLB7hWp6ZM+5dFXunSyhoX/Qu8ALUrUKyXY7MLOdLPXvsYpx
YEy5OTsZCdlebvziu2w8+aNOTxsctYF9cj8yraz8PtmKqgJ2Wg1seNLl7rfGwCWP
DGtvaPrS20cm+OIVD26or4zfR+6DGhilfz1BItoQejzA4ryVo3XEcYn9U11ph6mn
9Mu0W/XVl9AX44lliENPbcNmLDB5X65twv+1eIZkbevFRpSFsJYFg4Fdg6/0JK8g
B2zPyKmsTi+PgAx6dnEZeVNDhYY6P7E1OaGbXqIvNSdzGM6Ps3gbfIYiIOPD515B
kGi8y9kDKnNZ7PQrACTWU+u6stB8f4BoXBE7Au1+GNPbSRlqu9M=
=axEq
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-mmu-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM x86 MMU changes for 7.3
- Fix a bug where KVM would walk a newly created rmap without holding the rmap
lock (or mmu_lock) during aging.
- Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs.
- Remove a defunct masterclock update from kvm_xen_shared_info_init() that
could result in corrupting kvmclock, for a lose definition or "corrupting",
due to triggering an unnecessary switch to/from masterclock mode.
- Skip Xen runstate time updates if time has effectively gone backwards, so
that the guest doesn't report 100% steal time for a very, very long time.
- Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was
updating the wrong sub-leaf, and upstream KVM will soon provide all the
information needed by userspace to populate the CPUID field itself.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp7vSIACgkQOlYIJqCj
N/1FzRAAhtEbAmo1wQAfwCfC1zCGxxfNS45+KOUoa9qbBkmhqou0Vn648O4BxamK
7MJ2J9OZ25X5O+kkx0YTTqiRhPZ+z8NfAQeCAd2XhwqmLtKaY8PLea+Ei132ztLV
1UDHjxTjgrDrwZvV5V2q7IzHHWFxWm4HVX1BrArcsB2hndiq7Re+eYGF12IL2DEJ
nmL1Atc4xAVQYpeLqt9hT3mmbv09mifjEHGrzyP0xmCs6V8HKtpdM0tv9mdSvuRn
gTpnAmD9akfk4iT8xLW/1Di86a7KkWPqMU3te9GP5XBXeRld+iLZCPG1f5zq9wmT
I7wdScR8TPeEsawDIfwgW+SqbBE/452fbLk6spoIAJYysR8k5sXY5QMbmADznpBE
6MtDQgQ8IbevMZsb6NnfmYz2AFdBQcJN50/Zdk2SEXwXZJD6gZdNIVovlZURl0I5
9ApfHl7tSxW+Wz5aRL/iDCxQeoh+0cRXNbi4WRb6am3wgn8LVBvOgkZZNoTI1qE2
MN/Oc6WVavbMlOBC1mz9LuuiFugJnprWkxBjzvpzrlUBjt5m6lIni+9SctEArMuD
7tZbr1w8XGBwJU4xrMn16KC53+HAltuBgN0BK1umKtIGasn5K6cmGADpONclJ6RN
IKhcqIGwF+eqtYfthYIrGGsvMjrw9h1MGMMnLS3mt/J1GjX1VOo=
=oKIz
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-clocks-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM x86 PV clocks and timekeeping related changes for 7.3
- Remove a defunct masterclock update from kvm_xen_shared_info_init() that
could result in corrupting kvmclock, for a lose definition or "corrupting",
due to triggering an unnecessary switch to/from masterclock mode.
- Skip Xen runstate time updates if time has effectively gone backwards, so
that the guest doesn't report 100% steal time for a very, very long time.
- Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was
updating the wrong sub-leaf, and upstream KVM will soon provide all the
information needed by userspace to populate the CPUID field itself.
- Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is
zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State
Change request.
- Rework the so called "prepare" and "invalidate" guest_memfd hooks to prepare
for in-place private<=>shared conversion, and clean up a few warts along the
way.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp7vdQACgkQOlYIJqCj
N/00vA/+NmxB+Zsr7+TZo4NFiFcs/FK7rBb6psvlLuJN1oNLPw7dzdmPclSyv7li
RDWRF6SmuujxCO2W4LMc1Fz5IjN8/iYPHsEHnYCCxjDgFdEl7x1MOJ0xuXQOWgQw
icpWdYgWh9EoaKepn0EFVeF7WZFK7KhxmpJNz5HZEx3p110HfrSHbjl0LikySDst
19Jck5ZzTCVrbF58e5k6phzvvR6mRNeLS7BKvOM+u5U70+7P9AcTbihd8qz7vy0k
LlJUBZbp7NywjgIcqMTZGmBvsWoOAcvykBX9hNgjDdobVhh3Ft+hsmOxNt7yOoAl
llJznwRQvZItWGfGO8o9l+/pJI7bvGzQ6isXqdg3TbxWH7/d6HOdWoGiC8ya2x+k
UBDvlRgAH9KZuuE7E2m/ggM0hoLbWyNDV2qVo2WnmqbGG4SQRSA5hyq/pIov0hRY
kr0anBd/Pw8ZoO02RtlrSQkKODbdR7l3/lQDzHzSWKidJ8Eh+iqA30/oIQzQMCOw
3s/SIB19Jab4UEgS3aqvFNbsj+zXN2tT6NLiiSoodSp+sSP5OMJ46U4Sb/txn9EP
L035UIyLRAGFsIybvutSckT/Guv9aVeeK0F2CNRvzKrPUhaj3Vi2a7RvQtZZWeVd
EJLzM07Rx8msGZYq8Eg+9QkrDe5IgVjJvsZ5RrKeS7VJKivpFRU=
=yUfX
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-coco-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM guest_memfd and x86 CoCo changes for 7.3
- Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is
zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State
Change request.
- Rework the so called "prepare" and "invalidate" guest_memfd hooks to prepare
for in-place private<=>shared conversion, and clean up a few warts along the
way.
- Fix several issues with seeding KVM's pRNG, and rework the pRNG APIs to that
the pRNG can be sanely used in host code, not just guest code.
- Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via
KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs
via writes to an assigned VFIO device.
- Add syscall wrappers to assert success on a variety of pthreads and CPU
affinity APIs.
- Set vCPU pthread affinity as early as possible to reduce contention issues
that were surfaced by PREEMPT_LAZY, which result in runtimes of over a
minute on large hosts, versus the expected ~5 seconds.
- Rework the PMU counters test to run each testcase using a single VM with
many vCPUs for each sub-testcase, instead of using a unique VM for each
sub-testcase. This cuts the runtime by ~20x.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp8yNoACgkQOlYIJqCj
N/2s+w/+KtexoVLUzAy5DwIpm2g0pHqPAm5me7lTj1IuKyPxCksmmskNu3Nrfpn+
0fp0QyB3gfUFscwKgqq8waLHBRyszQvTgfF43h/Bvu7QoNgoBViu9ybkd91REkSM
CZj6ltUiHYJ1AmyB2khc5kPisLdZvEewSr1A2I9PudaPDa7DlOzN7DOCq4yePYkq
4Bt7oFKDB/BH1Cv/QlCpUbseKLydBX8Zgd9QZy8bTqRdEeHywXfbKv1b1AkX8Vc+
C0puEKrnJ6gluBTERYZ8+ibLBdewt/Hr+JdqlVtVkjSF2esGAWW//RuDlRj2zRzl
MTj5BK8MXotmrHp0RZD+QTcG6JEOVM5XtRTstJP4taKV1jKXxHcCa3+9jOSFbcU1
0E7cklQOwbgXIGw/Tc2fQ1wHu2E4Ee/r7C29qGxx6xUZQ6krUYBqRUZMZ0e5isK1
GW2EPpb8AXC6+XaoNeCP2rPhu6mB+GhC2Q4k9pKWjasDTLes6CkBfDf/+i5+LEXk
oQ3UTP1qGqUmm1y5m9h7+jUy4CdlzIbcLIUUt4X0naNJbpJsZqRvX3D4SKLf/wtV
ZPmmih2ha01gnErm3Znn8rxIIodEiwwXIRSSKi1IzBmghOJzgSXtynMzXmwOaQtW
4vdT22Yf1ip3pREfvtbL0pPDdxaJI4ngmm8Ia/ORHLYFbJmA5aM=
=fs2O
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-selftests2-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM selftests changes for 7.3, part 2
- Fix several issues with seeding KVM's pRNG, and rework the pRNG APIs to that
the pRNG can be sanely used in host code, not just guest code.
- Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via
KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs
via writes to an assigned VFIO device.
- Add syscall wrappers to assert success on a variety of pthreads and CPU
affinity APIs.
- Set vCPU pthread affinity as early as possible to reduce contention issues
that were surfaced by PREEMPT_LAZY, which result in runtimes of over a
minute on large hosts, versus the expected ~5 seconds.
- Rework the PMU counters test to run each testcase using a single VM with
many vCPUs for each sub-testcase, instead of using a unique VM for each
sub-testcase. This cuts the runtime by ~20x.
- Clean up nested SVM's handling of GPRs on L2<=>L1 transitions, reuse the
functionality for nested VMX, and drop the ucall hack that was fudging
around the lack of GPR switching on nVMX.
- Add a stress test to verify KVM doesn't clobber/drop #PF state, e.g. CR2,
across save/restore, including when L2 is active.
- Add a test to verify KVM_CREATE_VM accepts exactly what is reported by
KVM_CAP_VM_TYPES.
- Misc selftests fixes and cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp8wrYACgkQOlYIJqCj
N/2XHxAAgqT2MgtdpST9/n7pW1ifgiaRsxqFI09c2YheFVmpYzILVio4qaCLrO1e
92whJbOuiXgPWqPOU0FyS0wHICo5Q4aMJG3ECoAufeBifHM6+pR/mNE2q4U95rkw
jbLhEaRgWgeiHrRoPZo8KtH/gbzaXCJZJIkVfsRVFY10wPiymM/OSsSHeBHYsJAN
L9vmoJFa14tFu5c2rwPcpqgczWj2mKgVnlGVPRX3MizVXUuOwfatdChFOEEDxKCC
xsGieTbu19MBZuqcwzeIWLEw1e4TJcsi1YsCiwFGyV5r3eq2ZFvjMoLBJ7drLERs
awHaK8kG3qOo1KMZO0fVKi7gOq41h8VqsGDx/RKr3sKdd4aO67X5Sw5YZWB4xy68
TJduTwUn8DFHzl9VJK5iyyIw8R8E2EqlxlybMPh2B+luulzo5DkCD6XBjDo5TD1A
m2Ky7BzTzGOVlHpSj6uqf5+654BW/nEDMAekXFD7NkQfdZ8Bz27PpdA7l1sijFU0
0kDCRroAUqj/IVw+j2Ptnh+YbYYlKq/8OVu7RJmKw/nFSMSFLAiRn1U3xZedDrIW
HU08F3xZ/FxNIqu9a8biYJsLJovUFG5l2V2NGDy8POOkPLQ+bERjq366h50LHY5d
PPD8erp8cQwaX6Ypa3/K5lezUMTdDZowXevMfFt3/nV5gp37+Es=
=VqlG
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-selftests-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM selftests changes for 7.3, part 1
- Clean up nested SVM's handling of GPRs on L2<=>L1 transitions, reuse the
functionality for nested VMX, and drop the ucall hack that was fudging
around the lack of GPR switching on nVMX.
- Add a stress test to verify KVM doesn't clobber/drop #PF state, e.g. CR2,
across save/restore, including when L2 is active.
- Add a test to verify KVM_CREATE_VM accepts exactly what is reported by
KVM_CAP_VM_TYPES.
- Misc selftests fixes and cleanups
The dedicated hardware timestamp RX queue is allocated with q->index
equal to lif->ionic->nrxqs_per_lif. The normal txqcqs array only
contains the regular queue pairs, so using that index to set rxq->partner
can read one entry past txqcqs[] and then write through the derived
pointer.
Only link RX/TX partners for normal queue-pair indexes. Leave the hwstamp
RX queue unpaired, and make the XDP_TX path abort cleanly if an RX queue
has no TX partner.
Fixes: 8eeed8373e ("ionic: Add XDP_TX support")
Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
Reviewed-by: Shannon Nelson <sln@onemain.com>
Cc: stable@vger.kernel.org
Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260813083705.454897-1-anand.a.khoje@oracle.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
- Remove kvm_debugfs_dir if kvm_init() fails after creating KVM's debugfs.
- Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs
on x86.
- Add a per-VM bitmap to track which vCPU IDs have been "claimed" but for
which the vCPU isn't yet online, and use the bitmap to reject duplicate IDs
before calling into arch code. This allows arch code to consume vcpu_id
without having to worry about cross-vCPU clobbering (at least s390 and x86
have had related bugs).
- Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI
virtualization when the vCPU is freed to fix a use-after-free where hardware
will write to a freed vCPU's PID.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp7v0oACgkQOlYIJqCj
N/0d/Q/+MWjv5Ua3LXBIcdw34zm+ympYVwEs30x/GPM/434DR/JS7iKAL0ZaY/Wc
uQFlNOJ74Nwq59y63VFGhMJeJU3zh/T3aKS/yarlbeUn2kY5Mij856KnY1acKo1n
hVaW+S8xAYhyf4QWOugeheSU/nrQ6df13EA+zJWOcqWyeeWHm2cykpRAoNhglVJr
nu4lPewBqVBfLmNIMtWhV0L9YllFO9nhGA4Ho7mRCTp8McxXNoeqSmlqm5xbwa0U
iNgpyzEaZwXHBkjk/PbTNjmB4uRLIkhn3o+Ol0PRyt/R1OgJScwmlK+R04b+9nQa
wI0C4bh3lE5wyAFE78yIkju1DhTLHe5Vd748hONIyuwQ2fJoh5SCpFoPX59uND39
W4qU6I7DgAX4Oum0yuwBLMUaKTRtupgVHFlsXSIrx4Im95cYllUdfktLArmpdnfK
mFPOMPtD2x2RdFWhLQSGVLO+kG9IjRc06P0UVPwQPUc2CNfQKYgTqYjIPBn6KTef
U5ZQeN7TdZFg3Vchrwmis3PjYKeP/xdQPNOsMG9q7sXSdo8N4fCCsHfBjceEO5I5
s+DUbDJKruQW3MrwGTa6vCqOyLipNVxBXwgeOZQEDGbi+AynBB3QofY54jQSqwfL
SFbhfiTbcfu1JCogaCarZqclzVUp333LESNqqMljWMzDbCS9VwE=
=19dB
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-generic-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM arch-neutral and documentation changes for 7.3
- Remove kvm_debugfs_dir if kvm_init() fails after creating KVM's debugfs.
- Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs
on x86.
- Add a per-VM bitmap to track which vCPU IDs have been "claimed" but for
which the vCPU isn't yet online, and use the bitmap to reject duplicate IDs
before calling into arch code. This allows arch code to consume vcpu_id
without having to worry about cross-vCPU clobbering (at least s390 and x86
have had related bugs).
- Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI
virtualization when the vCPU is freed to fix a use-after-free where hardware
will write to a freed vCPU's PID.
1. Advertise already-supported capabilities.
2. Some bug fixes about timer and MMIO.
3. Some hardening about interrupt injection.
4. Replace kvm_err() with kvm_pr_unimpl().
5. Add FPU/LSX/LASX test cases for selftests.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmp9ca4WHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImelAuD/4jhprQWR9b8RMQ9bGYaBDml+98
fCRW8NPyicnct+97U/E9EXJrrMyyDOqJtOSnNQOVmTjz3IGQtzLoHULaJPqUv0Dh
7xUbpmb7qkqxrykUEUa81tDnClpISfLcgUBWKsg0VGLyF7MIEnbtECTadbzQEd10
hNXy/Pv8OiAIZe4rtlGWxOU5JxU6OVf0zEmXiS6cbqXrwxVl4STbF97/5ULqjU+D
4KMMs1IcOdf4klQeoE1oKvWsCiedZQBkKbtsv2hpDMmY4lUdheJg9+0atr8Oh7VS
TtlO6Fmt7ilK9eFOCapDcs4gf5WQgs8WXKAyVUYSoteyEXQ9kSF2bHMYiC+WaKhb
kMRR9ZyJa086FwDvW9/TyMrP8HLR4ORa7ksOeBnGt4Uv9A92ZbGqvEqLILPoKsIR
LBJUM17XuLlR9J56sYNtid3Rdq88VLo84Wfc0hW966b+6oNdOVQBPI2YRpk4wDT1
Mtra60dtzwQ3jCW/GTjJThueEC4lqOFKHpYPIP3rd4aL8oCvfgLYlYZ4TiXHUjpX
MgQ9rm8nDZAWipsjvt2yADFnv3YW4kD6hrn1S0EaDJXsTtT7pB6Mr0jlxQE/ZJdA
ibXSubO5cakIdpMnAylL78ZyGZOWn6YOSG1pEjHjkI+in73sZ5a89k4s5ErxKxtB
Hnc/FXwVWbylUdJkKw==
=eMRy
-----END PGP SIGNATURE-----
Merge tag 'loongarch-kvm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD
LoongArch KVM changes for v7.3
1. Advertise already-supported capabilities.
2. Some bug fixes about timer and MMIO.
3. Some hardening about interrupt injection.
4. Replace kvm_err() with kvm_pr_unimpl().
5. Add FPU/LSX/LASX test cases for selftests.
- Add the kvm-x86 tree to KVM x86 entries so that humans and robots alike can
more easily find in-flight x86 changes.
- Add a dedicated entry for guest_memfd, with the usual suspects as
Maintainers, and David Hildenbrand as a Reviewer.
- Add Sean as a Reviewer for overall KVM.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmp7v8cACgkQOlYIJqCj
N/3v9BAArbwIeJkE9Tf5QhsMI1tvCPQoWUuOHuZb2SbKDVrapiebgwgl373jn2cT
Sz1wf+Ka7b/eEJfHYytCuRdTM56jK5HoK6mH2HlNEPPfQxWiHbsVDtdSTCI0YiV6
j/6bUtZGp90bFnWK615au8+FN2CLLk6R74Yd8vIcFbwEueqT7Qvvq5i3FwIJYIS2
IfNy5Ab+dWOp1k1p9veSuhbS2ED8dmoOzDA2aYHqxWU/OrAn9g0r/8uedsrZexKb
MTe7/6yHg3AdXiss2YJGs2ZnHeg0kdEsFI6XwDkxprUodF3OGgJaXxpSHdXI0eVt
eKmMgzrYDr3DeJtxqsmGv28LuS3eRrutlVD7I+v0ynXyk5H9rhWapCR/03rNW9MY
4IVzLBmVpaEfPGJr+5REVdSM2p7wwvhf2S5hb82iQcUA+RZLvyQdfKLgYq/Qfa05
JNCvdZULIecwEjpWfxIebkGEhJrXP4UZAsPN6dj+3h5Ate6cZNWQ+h6RoT8sYcio
5PxpsgAHbwgeayw+nR3OH7XcBOi0oGGerdJFDAfnL16s/7DF1e5oQztky/xNKh/A
l1wMB07FOcYtwIWfLQWGwepAw0anUvKe7DjmEzlW6yYGENXc+87g7t9WtA4Y4IzL
2BiyYBZTlg0YiIe8qGmJYKdM7Oa3+/qsG3ieHB8sX6XWUTcpwlk=
=X4/v
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-maintainers-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM MAINTAINERS changes for 7.3
- Add the kvm-x86 tree to KVM x86 entries so that humans and robots alike can
more easily find in-flight x86 changes.
- Add a dedicated entry for guest_memfd, with the usual suspects as
Maintainers, and David Hildenbrand as a Reviewer.
- Add Sean as a Reviewer for overall KVM.
KVM: s390: Features and Fixes for 7.3
- merged kvms390/master to pick up additional fixes that came too late
for 7.2
- Fixes for vfio-ap
- Fixes for the gmap rework
- Fixes for vsie
- AI triggered fixes all over
- diag9c tracing
- code move preparation for the additional arm64 support
- enable CONTEXT_ANALYSIS
- update to vfio maintainer file location
KVM/riscv changes for 7.3
- Svadu/Zicfiss/Zicfilp FWFT support for Guest
- Use try_cmpxchg for IMSIC MRIF RMW
- More arch-specific tracepoints in KVM RISC-V
- Eager Page Splitting for KVM RISC-V
- Optimize hfence request handling for SMP Guests
- Improve dirty log clearing by skipping zero bits in mask
- Guard HFENCE range loops against overflow
- CPU PM notifiers in KVM RISC-V for non-retentive idle states
- Fix kernel-mode vector context save/restore for Guest
Add the missing include leading to the error:
error: implicit declaration of function ‘FIELD_GET’ [-Werror=implicit-function-declaration]
184 | if (FIELD_GET(MON_FAULT_STATUS_MASK, val) == MON_FAULT_LVL1_UPR)
| ^~~~~~~~~
cc1: all warnings being treated as errors
Fixes: cbe31d5ce4 ("thermal/drivers/armada: Use bitfield and bitmask macros")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608082242.drjXuzsN-lkp@intel.com/
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260811094747.2940616-1-daniel.lezcano@kernel.org
Add missing file resulting from a manual application of the change
below after fixing a conflict in the Makefile.
Fixes: 948ee3a74f ("thermal/drivers/qcom: add support for PMIC5 Gen3 ADC thermal monitoring")
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260811145427.3089426-1-daniel.lezcano@kernel.org
IPv4 and IPv6 input preserve an skb->sk association installed by
bpf_sk_assign() so that local delivery can use the selected socket under
RCU. Both address families can also prefetch a socket in UDP early demux.
In both paths (BPF and UDP early demux) a reference is not guaranteed to
be held on the socket.
When a multicast packet is not locally deliverable, IPv6 hands the
original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the
original skb when local delivery is not needed. Either path can put the
skb on an unresolved multicast route queue or forward it after the
receive-side RCU section ends.
After the prefetched socket is destroyed, a later skb free invokes
sock_pfree() and dereferences the stale skb->sk. Orphan the skb before
each non-local multicast forwarding path. Local delivery retains the
original skb; the existing skb_clone() calls provide multicast forwarding
with a socket-free clone.
Fixes: cf7fbe660f ("bpf: Add socket assign support")
Fixes: 08842c43d0 ("udp: no longer touch sk->sk_refcnt in early demux")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/0c52eb3d7532aaf8bccf37e0f7c922143c639735.1786552223.git.zhilinz@nebusec.ai
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
acpi_pcc_retrieve_biosdata() rejects SINF packages only when
pcc->num_sifr is strictly less than hkey->package.count, then
unconditionally writes a trailing sentinel at
pcc->sinf[hkey->package.count]. But pcc->sinf[] is allocated with
exactly pcc->num_sifr elements (valid indices 0..num_sifr-1), so that
write needs num_sifr strictly greater than package.count to stay in
bounds -- num_sifr == package.count passes the existing check but
still overflows by one element.
This is exactly the case probe()'s existing num_sifr++ workaround
("Some DSDT-s have an off-by-one bug where the SINF package count is
one higher than the SQTY reported value") is written to accommodate:
when a DSDT's SINF package count equals SQTY+1, the workaround makes
num_sifr equal to package.count, which is precisely the boundary that
overflows here. Found via UBSan (array-index-out-of-bounds) on
hardware where HKEY.SQTY returns 37 and HKEY.SINF()'s package has 38
elements: num_sifr becomes 38 after the += 1 workaround, the loop
correctly fills indices 0..37, and the sentinel write then targets
index 38, one past the end -- a silent 4-byte heap overflow on kernels
without CONFIG_UBSAN.
Tightening the rejection check to num_sifr <= package.count would
avoid the overflow but breaks probe() entirely on exactly this
hardware, since num_sifr == package.count is the case the off-by-one
workaround exists to support. Nothing else in the driver reads this
sentinel value back, so simply skip the write when there is no room
for it instead.
Fixes: a3d0dbd18c ("platform/x86: panasonic-laptop: simplify allocation of sinf")
Cc: stable@vger.kernel.org
Signed-off-by: Hilgad Montelo <hilgad.montelo@gmail.com>
Link: https://patch.msgid.link/20260813221744.25668-4-hilgad.montelo@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Zhiling Zou says:
====================
net: fix IP6GRE header length before capping tunnel headroom
We found and validated an issue in IP tunnel headroom accounting. The bug is
reachable by a non-root user via user and net namespace.
We've tested it, and it should not affect any other functionality.
We will provide detailed information about the bug
in this email, along with a PoC to trigger it.
---- details below ----
Bug details:
IP tunnel devices derive advertised headroom from lower output devices. A
namespace-local stack of tunnel devices can make that advertised reservation
larger than the 16-bit skb header offsets can represent. Once IP output
reserves that space and records network or transport header offsets, later skb
head expansion can wrap those offsets and leave header helpers pointing into
headroom instead of the packet area.
For IP6GRE, there is an earlier accounting bug that has to be fixed first:
ip6gre_tnl_link_config_route() folds the lower device's hard_header_len into
the tunnel device's hard_header_len whenever header_ops is set. That is wrong
for both header_ops users. ip6gretap and ip6erspan have a fixed Ethernet
hardware header length, while an NBMA ip6gre tunnel's header_ops creates only
the tunnel header: GRE, optional FOU or GUE, and the outer IPv6 header. The
lower device header is needed headroom, not part of the tunnel device's
hardware header.
This series first fixes that IP6GRE hardware-header accounting, then caps the
advertised IP tunnel needed_headroom at the same 512-byte limit already used
by the runtime tunnel transmit path. Tunnel transmit can still expand the skb
when a packet needs more headroom, so nonsensical stacked configurations may
pay an extra reallocation but cannot publish an unbounded reservation to upper
layers.
====================
Link: https://patch.msgid.link/cover.1786542637.git.zhilinz@nebusec.ai
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
IP tunnel devices derive their advertised needed_headroom from lower
output devices. A stack of user-created devices can make the derived
value larger than the 16-bit skb header offsets can represent. Once IP
output reserves it, skb head expansion can wrap those offsets.
The runtime transmit path already caps a growing needed_headroom at 512.
Apply the same cap when tunnel configuration publishes needed_headroom
derived from a lower output device.
Capping the advertised value is safe: IP tunnel transmit still expands
the skb when a packet needs more headroom. A nonsensical stacked
configuration can therefore incur an extra reallocation, but it cannot
publish an unbounded reservation to upper layers.
Fixes: 1a37e412a0 ("net: Use 16bits for *_headers fields of struct skbuff")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/ba04a1fd6bfae2377607fad5d8f80f7eb80fd4c4.1786542637.git.zhilinz@nebusec.ai
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ip6gre_tnl_link_config_route() accumulates the lower device's hardware
header length into dev->hard_header_len whenever header_ops is set. This
is incorrect for both users of header_ops.
ip6gretap and ip6erspan have a fixed Ethernet hardware header length.
For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header,
the optional FOU or GUE header, and the outer IPv6 header. The lower
device header is headroom needed later, not part of the tunnel device's
hardware header.
Keep the lower device header in needed_headroom. Set hard_header_len to
the tunnel header length only for ARPHRD_IP6GRE devices with header_ops,
and leave the fixed Ethernet header length unchanged for tap and erspan
devices.
Fixes: 832ba59649 ("net: ip6_gre: set dev->hard_header_len when using header_ops")
Cc: stable@vger.kernel.org
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/64b46542bbe1701f07702aaa50273e2a87903db5.1786542637.git.zhilinz@nebusec.ai
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The get_instance_id() macro walks the per-type attribute array with
'i <= instances_count'. Each array is allocated with exactly
instances_count entries, so the valid range is [0, instances_count)
and the last iteration reads one element past the end. On a name miss
that out-of-bounds attribute_name is handed to strcmp(), which reads on
until it finds a NUL byte.
Every kobject in these ksets is built from an entry that was populated,
so a miss does not look reachable from sysfs today. The bound is wrong
either way and the read is out of bounds.
The matching macro in hp-bioscfg carried the same off-by-one and was
corrected by commit 25150715e0 ("platform/x86: hp-bioscfg: Fix kernel
panic in GET_INSTANCE_ID macro"). That macro takes a kobject pointer
out of the out-of-bounds element and dereferences it, so it could fault.
This one reads a char array.
Use '<' to match the allocation.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add DMI match and power-limit table entry for the ASUS TUF Dash F15
(2022), board FX517ZR, an Alder Lake + RTX 3070 laptop.
AC and DC min/max values for ppt_pl1_spl, ppt_pl2_sppt,
nv_dynamic_boost and nv_temp_target were referenced from ASUS Armoury
Crate's manual performance-tuning mode on Windows for this exact model.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: AbdElRahman Soliman <abdelrahman7987@gmail.com>
Link: https://patch.msgid.link/20260816174118.28012-1-abdelrahman7987@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
syzbot reported a suspicious RCU usage warning in ip6_pkt_drop():
WARNING: suspicious RCU usage in ip6_pkt_drop
include/net/addrconf.h:389 suspicious rcu_dereference_check() usage!
Call Trace:
__in6_dev_get_safely include/net/addrconf.h:389 [inline]
ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620
ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651
xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806
process_one_work kernel/workqueue.c:3322 [inline]
process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486
When commit 4f4920669d ("xfrm: Reinject transport-mode packets through
workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue,
the reinjection loop ceased running in softirq context. Workqueue workers
run in process context where local_bh_disable() does not enter an RCU
read-side critical section under CONFIG_PREEMPT_RCU.
Because finish callbacks (such as ip6_rcv_finish) expect to run under an
RCU read lock (performing route lookups, l3mdev lookups, and accessing
RCU-protected data structures), invoking them in workqueue context without
rcu_read_lock() triggers RCU lockdep warnings.
Furthermore, packets queued to the workqueue via xfrm_trans_queue_net()
may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref).
Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev
with blackhole_netdev, so dst entries do not keep skb->dev alive while
queued in the workqueue.
Fix these issues by:
1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the
caller's RCU section to ensure dst is reference-counted before queuing.
2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue
deferral so skb->dev remains valid during finish() callback processing.
3. Acquiring rcu_read_lock() around the finish callback invocation loop in
xfrm_trans_reinject().
Fixes: 4f4920669d ("xfrm: Reinject transport-mode packets through workqueue")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Liu Jian <liujian56@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
xfrm_state_netlink() builds the ALLOCSPI response with
dump_one_state(), which already calls alloc_compat() with the response
skb and header.
xfrm_alloc_userspi() then calls alloc_compat() again, but passes the
original request skb and its header. For a compat request, the
translator therefore interprets the 228-byte compat xfrm_userspi_info
as the 232-byte native layout and reads four bytes past the declared
payload. It also publishes the translated child through the request's
frag_list.
A multicast clone of the request shares skb_shared_info and can observe
that child. xfrm_user_rcv_msg() frees it after the request handler
returns, racing a compat receiver which may still be copying from it and
resulting in a use-after-free.
Remove the redundant conversion. The response keeps its correct compat
translation from dump_one_state(), and no child is attached to the
inbound request.
Fixes: 5f3eea6b7e ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator")
Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
xfrm6_local_rxpmtu() and xfrm6_local_error() dereference skb->sk as if it
always pointed at a full IPv6 socket.
That is not guaranteed. TCP SYN-ACK skbs can be owned by a
TCP_NEW_SYN_RECV request_sock while the output path itself is driven by the
full listener. If rerouting selects an IPv6 XFRM tunnel route with a lower
MTU, the local PMTU/error handling path can reach these callbacks with that
mini-socket still attached to the skb.
The callbacks then miscast the request socket as a full inet/IPv6 socket and
can read beyond the request_sock allocation when they access inet_sock or
ipv6_pinfo state.
Resolve the owner with skb_to_full_sk() in both callbacks and bail out when
no full socket is attached. This matches the surrounding XFRM IPv6 PMTU/error
logic, which already reasons about full sockets with skb_to_full_sk().
Fixes: dd767856a3 ("xfrm6: Don't call icmpv6_send on local error")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
When the start of an inner packet is split across two outer packets
such that fewer than 4 bytes land at the end of the first one,
__input_process_payload() saves those bytes as a runt and skips the
iplen/iphlen validation performed for in-place packets. When the
continuation packet arrives, iptfs_reassem_cont() only requires the
declared inner length to be >= sizeof(ra_runt) (6) before allocating
the reassembly skb with that attacker-controlled length.
However, __iptfs_iphlen() always returns the fixed minimum IP header
size (20 for IPv4, 40 for IPv6), so for an inner IPv4 tot_len in
[6, 19] the header-completion copy writes past the declared packet
length, and the subsequent "ipremain -= copylen" underflows to ~4GB,
leaving the payload copy length bounded only by blkoff (up to 64KB).
At runtime the skb_put() tailroom check turns this into
skb_over_panic(), i.e. an unprivileged kernel panic (DoS), reachable
locally via userns+netns IPTFS SAs and remotely against IPTFS VPN
gateways when the decrypted outer skb is linear (e.g. AF_PACKET taps,
tun/tap delivery).
Align the runt path with the normal path by requiring the declared
inner length to cover at least the IP header size. This also subsumes
the previous >= sizeof(ra_runt) check, since the minimum IP header
is always larger than the runt buffer.
This issue was found by the autokbug dynamic kernel fuzzer at
Tencent Yunding Lab.
Fixes: 0756947654 ("xfrm: iptfs: handle received fragmented inner packets")
Reported-by: Henry Martin <bsdhenrymartin@gmail.com>
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
xfrm_nlmsg_multicast() requires the RCU read lock to be held because it
safely dereferences the net->xfrm.nlsk pointer using rcu_dereference().
When it is called from xfrm_send_migrate_state(), the RCU read lock is not
held, which triggers a suspicious RCU usage warning:
WARNING: suspicious RCU usage
net/xfrm/xfrm_user.c:1630 suspicious rcu_dereference_check() usage!
Call Trace:
lockdep_rcu_suspicious+0x13f/0x1d0 kernel/locking/lockdep.c:6876
xfrm_nlmsg_multicast+0x1d8/0x1f0 net/xfrm/xfrm_user.c:1630
xfrm_send_migrate_state+0x870/0xae0 net/xfrm/xfrm_user.c:3340
xfrm_do_migrate_state+0x1749/0x1e90 net/xfrm/xfrm_user.c:3507
xfrm_user_rcv_msg+0x7a8/0xf30 net/xfrm/xfrm_user.c:3907
Fix this by wrapping the xfrm_nlmsg_multicast() call in
xfrm_send_migrate_state() with rcu_read_lock() and rcu_read_unlock().
Fixes: a9d155ea9b ("xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+c0e99a1aa85a286d7a3b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c0e99a1aa85a286d7a3b
Link: https://syzkaller.appspot.com/ai_job?id=8977f559-3a7e-4bb5-b4d6-1196956260b6
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
The deferred-device pass in xfrm_dev_state_flush() finds states under
xfrm_state_dev_gc_lock, but drops the lock before calling
xfrm_dev_state_free() because the driver callback may sleep. The device
GC list does not hold an xfrm_state reference, so the state GC worker can
destroy the same state concurrently.
The race can proceed as follows:
CPU 0 CPU 1
find x on the device GC list
drop xfrm_state_dev_gc_lock
read x->xso.dev
xfrm_state_gc_destroy(x)
xfrm_dev_state_free(x)
xfrm_state_free(x)
continue xfrm_dev_state_free(x)
Both paths can invoke the driver callback and drop the device reference.
CPU 0 can also access the xfrm_state after CPU 1 has freed it.
KASAN reported:
BUG: KASAN: slab-use-after-free in xfrm_dev_state_free+0x24c/0x2a0
Read of size 8 at addr ffff88810bbaa960 by task poc/102
Call Trace:
xfrm_dev_state_free+0x24c/0x2a0
xfrm_dev_state_flush+0x353/0x400
xfrm_dev_event+0x26d/0x3a0
notifier_call_chain+0xc0/0x280
__dev_notify_flags+0x169/0x250
netif_change_flags+0xe7/0x160
dev_change_flags+0x96/0x220
devinet_ioctl+0x7f4/0x1880
Allocated by task 87:
xfrm_state_alloc+0x1e/0x5c0
xfrm_add_sa+0xe7f/0x5820
xfrm_user_rcv_msg+0x4f3/0x940
Freed by task 57:
kmem_cache_free+0xcb/0x3d0
xfrm_state_gc_task+0x4a8/0x650
process_one_work+0x63a/0x1070
Serialize xfrm_state destruction against the deferred-device pass with a
mutex. Keep xfrm_state_dev_gc_lock limited to list operations and retain
the existing callback and device-reference release ordering.
Fixes: 07b87f9eea ("xfrm: Fix unregister netdevice hang on hardware offload.")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
