Merge tag 'xfs-fixes-7.2-rc2' of git://git./fs/xfs/xfs-linux

Pull xfs fixes from Carlos Maiolino:
 "A collection of bugfixes and some small code refactoring"

* tag 'xfs-fixes-7.2-rc2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: simplify __xfs_buf_ioend
  xfs: fix handling of synchronous errors in xfs_buf_submit
  xfs: remove xfs_buf_ioend
  xfs: improve the xfs_buf_ioend_fail calling convention
  xfs: use null daddr for unset first bad log block
  xfs: fix memory leak in xfs_dqinode_metadir_create()
  xfs: release dquot buffer after dqflush failure
  xfs: also mark the buffer stale on verifier failure in xfs_buf_submit
  xfs: open code xfs_buf_ioend_fail in xfs_buf_submit
  xfs: fix AGFL extent count calculation in xrep_agfl_fill
  xfs: simplify the failure path in xfs_buf_alloc_vmalloc
  xfs: fix incorrect use of gfp flags in xfs_buf_alloc_backing_mem
  xfs: lift setting __GFP_NOFAIL from xfs_buf_alloc_kmem to the caller
  xfs: split up xfs_buf_alloc_backing_mem

Merge tag 'for-linus-7.2a-rc2-tag' of git://git./linux/kernel/git/xen/tip

Pull xen fixes from Juergen Gross:

 - rename function parameters and a comment related to
   xen_exchange_memory() (Jan Beulich)

 - replace __ASSEMBLY__ with __ASSEMBLER__ (Thomas Huth)

 - add some sanity checking to the Xen pvcalls frontend driver (Michael
   Bommarito)

 - fix error handling in the Xen gntdev driver (Wentao Liang)

 - fix several minor bugs in Xen related drivers (Yousef Alhouseen)

* tag 'for-linus-7.2a-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  x86/Xen: correct commentary and parameter naming of xen_exchange_memory()
  xenbus: reject unterminated directory replies
  xen/gntalloc: validate grant count before allocation
  xen/gntalloc: make grant counters unsigned
  xen/front-pgdir-shbuf: free grant reference head on errors
  xen/gntdev: fix error handling in ioctl
  xen: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
  xen/pvcalls: bound backend response req_id before indexing rsp[]

Merge tag 'gpio-fixes-for-v7.2-rc2' of git://git./linux/kernel/git/brgl/linux

Pull gpio fixes from Bartosz Golaszewski:

 - check the return value of gpiochip_add_data() in gpio-mvebu and
   gpio-htc-egpio

 - avoid locking context issues with GPIO drivers using the shared GPIO
   proxy by only allowing sleeping operations (atomic GPIO ops don't
   really make sense in shared context anyway)

 - with the above: restore non-sleeping GPIO access in pinctrl-meson

 - fix return value on OOM in gpio-timberdale

 - fix interrupt handling in gpio-mt7621

 - support both A and B variants of NCT6126D in gpio-f7188x

* tag 'gpio-fixes-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  pinctrl: meson: restore non-sleeping GPIO access
  gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe
  gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips
  gpio: mt7621: more robust management of IRQ domain teardown
  gpio: mt7621: avoid corruption of shared interrupt trigger state
  gpio: shared-proxy: always serialize with a sleeping mutex
  gpio-f7188x: Add support for NCT6126D version B
  gpio: htc-egpio: use managed gpiochip registration
  gpio: mvebu: fail probe if gpiochip registration fails

Merge tag 'device-id-rework' of git://git./linux/kernel/git/ukleinek/linux

Pull mod_devicetable.h header split from Uwe Kleine-König:
 "Split <linux/mod_devicetable.h> in per subsystem headers

  <linux/mod_devicetable.h> is included transitively in nearly every
  driver in an x86_64 allmodconfig build of v7.1:

      $ find drivers -name \*.o -not -name \*.mod.o | wc -l
      21330
      $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
      17038

  The result of this mixture of different and unrelated subsystem
  details is that even when touching an obscure device id struct most of
  the kernel needs to be recompiled. Given that each driver typically
  only needs one or two of these structures, splitting into per
  subsystem headers and only including what is really needed reduces the
  amount of needed recompilation.

  This split is implemented in the first commit and then after some
  preparatory work in the following commits, the last two replace
  includes of <linux/mod_devicetable.h> by the actually needed more
  specific headers.

  There are still a few instances left, but the ones with high impact
  (that is in headers that are used a lot) and the easy ones (.c files)
  are handled. These remaining includes will be addressed during the
  next merge window"

* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
  Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)
  Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers)
  parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h>
  media: em28xx: Add include for struct usb_device_id
  LoongArch: KVM: Add include defining struct cpu_feature
  ALSA: hda/core: Add include defining struct hda_device_id
  usb: dwc2: Add include defining struct pci_device_id
  platform/x86: int3472: Add include defining struct dmi_system_id
  platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
  i2c: Let i2c-core.h include <linux/i2c.h>
  of: Explicitly include <linux/types.h> and <linux/err.h>
  platform/x86: msi-ec: Ensure dmi_system_id is defined
  usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>
  driver core: platform: Include header for struct platform_device_id
  driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
  media: ti: vpe: #include <linux/platform_device.h> explicitly
  mod_devicetable.h: Split into per subsystem headers

Merge tag 'ata-7.2-rc2' of git://git./linux/kernel/git/libata/linux

Pull ata fixes from Damien Le Moal:

 - Quirk the Phison PS3111-S11 SSD with NOLPM due to its defective
   link power management (Bryam)

 - Strengthen checks on a device concurrent positioning range
   information to make sure to reject any invalid report (Bryam)

 - Fix probe error handling in the pata_pxa and sata_gemini
   drivers (Myeonghun, Wentao)

 - Limit buffer size of replies from translated commands to what
   libata actually generated (Karuna)

* tag 'ata-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: libata-scsi: limit simulated SCSI command copy to response length
  ata: pata_pxa: Fix DMA channel leak on probe error
  ata: sata_gemini: unwind clocks on IDE pinctrl errors
  ata: libata-core: Reject an invalid concurrent positioning ranges count
  ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD

Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)

Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers)

<linux/mod_devicetable.h> is included in a many files:

$ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l
1598

; some of them are widely used headers. To stop mixing up different and
unrelated driver( type)s let the subsystem headers only use the subset
of the recently split <linux/mod_devicetable.h> that are relevant for
them.

The fallout (I hope) is addressed in the previous commits that handle
sources relying on e.g. <linux/i2c.h> pulling in the full legacy header
and thus providing pci_device_id.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h>

Currently <linux/compiler.h> isn't included at all (not even
transitively) in <asm/ptrace.h>.
arch/parisc/kernel/asm-offsets.c just happens to include the following
chain of includes before <asm/ptrace.h>:

<linux/sched.h>
-> <asm/processor.h>
-> <asm/hardware.h>
-> <linux/mod_devicetable.h>
-> <linux/uuid.h>
-> <linux/string.h>
-> <linux/compiler.h>

. That chain will be broken, because in one of the next commits
<asm/hardware.h> is changed to only include <linux/device-id/parisc.h>
instead of <linux/mod_devicetable.h>. So to ensure
arch/parisc/kernel/asm-offsets.c knows about unlikely() even after that
change, #include <linux/compiler.h> explicitly.

Link: https://patch.msgid.link/0574a2b73363c3cbf21c55c27455c3cecfb33583.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

media: em28xx: Add include for struct usb_device_id

Traditionally <linux/mod_devicetable.h> was a header defining a plethora
of structs, among them struct usb_device_id. This was split now with the
objective that only the relevant bits are included.

Currently <linux/mod_devicetable.h> is transitively included in
drivers/media/usb/em28xx/em28xx.h via:

drivers/media/usb/em28xx/em28xx.h ->
<linux/i2c.h> ->
<linux/acpi.h> ->
<linux/device.h> ->
<linux/device/driver.h> ->
<linux/mod_devicetable.h

To keep struct usb_device_id available once <linux/device/driver.h>
stops including <linux/mod_devicetable.h>, include it the header
providing that struct explictly.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/e72de5b4b9f1aa77a3c19a5e698a195dfd81ae0b.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

LoongArch: KVM: Add include defining struct cpu_feature

Traditionally <linux/mod_devicetable.h> was a header defining a plethora
of structs, among them struct cpu_features. This was split now with the
objective that only the relevant bits are included.

Currently <linux/mod_devicetable.h> is transitively included in
arch/loongarch/kvm/main.c via:

arch/loongarch/kvm/main.c ->
<linux/kvm_host.h> ->
<linux/entry-virt.h> ->
<linux/resume_user_mode.h> ->
<linux/memcontrol.h> ->
<linux/cgroup.h> ->
<linux/kernel_stat.h> ->
<linux/interrupt.h> ->
<linux/hardirq> ->
<asm/hardirq.h> ->
<linux/irq.h> ->
<asm/irq.h> ->
<linux/irqdomain.h> ->
<linux/of.h> ->
<linux/mod_devicetable.h>

To keep struct cpu_features available once <linux/of.h> stops including
<linux/mod_devicetable.h>, include it here explicitly.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/052feec0e04ea8f5b2706a19a5b236679eed0aba.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

ALSA: hda/core: Add include defining struct hda_device_id

Traditionally all *_device_id were defined in a single header
<linux/mod_devicetable.h>. This was split now with the objective that
only the relevant bits are included. So including <linux/pci.h> won't be
enough to get a definition of (the unrelated to pci) struct
hda_device_id.

Add an explicit include for the header defining struct hda_device_id to
keep working when <linux/pci.h> stops providing this defintion.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/376883bc5889d5cca01efb6f8d4e07a20158f2b8.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

usb: dwc2: Add include defining struct pci_device_id

Up to now <linux/acpi.h> includes <linux/mod_devicetable.h> that
provides struct pci_device_id. However <linux/mod_devicetable.h> was
split into per bus headers and <linux/acpi.h> will only include the acpi
related one (and similar for other bus headers).

As struct pci_device_id is used in drivers/usb/dwc2/core.h, add an
include to ensure it's defined also after the includes in <linux/acpi.h>
are tightened.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/bddfcdfaf36d735c244e03efada6083ef98ebd51.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

platform/x86: int3472: Add include defining struct dmi_system_id

Currently <linux/mod_devicetable.h> is included transitively in
int3472.h via

<linux/clk-provider.h> ->
<linux/of.h> ->
<linux/mod_devicetable.h>

However these includes will be tightend such that only the bits relevant
for of will be provided by <linux/of.h>. To ensure that dmi_system_id
stays around, include the respective header explicitly.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/0ba52730f67dc995d9d896b81fa6a7320bf8cb4b.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

platform/x86: x86-android-tablets: Add include defining struct dmi_system_id

Currently <linux/i2c.h> includes <linux/mod_devicetable.h> transitively
which ensures that struct dmi_system_id is defined in
drivers/platform/x86/x86-android-tablets/x86-android-tablets.h. However
this include in <linux/i2c.h> will be replaced by one for i2c_device_id
only. To ensure that dmi_system_id is available add the include for that
explicitly.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/32928d9ee47cefc7dfc4c385c06bd5e598b0fca1.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

i2c: Let i2c-core.h include <linux/i2c.h>

The subsystem private header i2c-core.h uses several symbols defined in
<linux/i2c.h>, e.g. struct i2c_board_info and i2c_lock_bus()). This
doesn't pose a problem in practise because all files including
"i2c-core.h" also include <linux/i2c.h>.

To make this more robust add an include statement for <linux/i2c.h>
making the header self-contained.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/46aa85ab3dc4e63bfb5bd8ff1fd212a3d0e31f58.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

of: Explicitly include <linux/types.h> and <linux/err.h>

<linux/of_platform.h> uses resource_size_t and relies on the transitive
include <linux/mod_devicetable.h> -> <linux/types.h>. It also uses error
constants and thus relying on the include chain
<linux/mod_devicetable.h> -> <linux/uuid.h> -> <linux/string.h> ->
<linux/err.h>.

With the plan to split <linux/mod_devicetable.h> per subsystem and then
only letting of_platform.h include the of-specific bits (which don't
require these two headers), add the needed includes explicitly to keep
the header self-contained.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/a730991bc8813cf70c2445064ea425291538f709.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

platform/x86: msi-ec: Ensure dmi_system_id is defined

Currently <linux/acpi.h> includes <linux/mod_devicetable.h> and thus
dmi_system_id is available for the driver. To disentangle includes
<linux/acpi.h> will be changed to only include the header for
acpi_device_id instead of the full <linux/mod_devicetable.h>. To prepare
for that include the dedicated header for struct dmi_device_id.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/600c7ab3263dcb8cee39b43dbd313eba8abef376.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>

All consumers of the latter also include the former, but without that
struct usb_driver and struct usb_device_id (and maybe more) are not
defined. Add an include for <linux/usb.h> to make the header
self-contained.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/82219ab65d16ee5bfe5a35d11bc938baac3fd3bc.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

driver core: platform: Include header for struct platform_device_id

Platform drivers can define an array containing the supported device
variants to be assigned to the struct platform_driver's .id_table.

While a forward declaration of struct platform_device_id is technically
enough to make the driver self-contained, it's reasonable to provide the
(very lightweight) data type definition for that array in
<linux/platform_device.h> to not add that burden to all platform drivers
with an id-table.

Note that currently <linux/device.h> transitively includes
<linux/mod_devicetable.h> that provides struct platform_device_id. But
that include is planned to be replaced by a tighter set of includes that
only define the structures relevant for the stuff in <linux/device.h>.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/4ca29592c9d1c6d528a65e05b80af7355f3c79c5.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver

struct device_driver contains pointers of type struct of_device_id* and
struct acpi_device_id* but doesn't ensure these are defined. To make the
header self-contained add the (very lightweight) includes that contain
the respective definitions.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/199ba71b4ac73f4b4d9f5d2be635c96eec73c70e.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

media: ti: vpe: #include <linux/platform_device.h> explicitly

The driver uses several symbols and structs defined in that header. The
header is currently included transitively via

"vip.h" ->
<media/v4l2-ctrls.h> ->
<media/media-request.h> ->
<media/media-device.h> ->
<linux/platform_device.h>

which seems to be on the lower end of the scale between random and
reliable.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/9f2e0e001eec087f00ac2c5af2de2e8f6d0978c1.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

mod_devicetable.h: Split into per subsystem headers

<linux/mod_devicetable.h> is included transitively in nearly every
driver in an x86_64 allmodconfig build of v7.1:

$ find drivers -name \*.o -not -name \*.mod.o | wc -l
21330
$ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
17038

The result is that even when touching an obscure device id struct most
of the kernel needs to be recompiled. Given that each driver typically
only needs one or two of these structures, splitting into per subsystem
headers and only including what is really needed reduces the amount of
needed recompilation.

Implement the first step and define each device id struct in a separate
header (together with its associated #defines).

<linux/mod_devicetable.h> is modified to include all the new headers to
continue to provide the same symbols.

Several headers currently include <linux/mod_devicetable.h>, those that
are most lukrative to include only their subsystem headers only are:

$ git -C source grep -l mod_devicetable.h include/linux | while read h; do echo -n "$h:"; find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l $h | wc -l; done | sort -t: -k2 -n -r | head
include/linux/of.h:10897
include/linux/pci.h:7920
include/linux/acpi.h:7097
include/linux/i2c.h:5402
include/linux/spi/spi.h:1897
include/linux/dmi.h:1643
include/linux/usb.h:1222
include/linux/input.h:1205
include/linux/mdio.h:835
include/linux/phy.h:733

struct cpu_feature isn't really a device_id struct. That is kept in
<linux/mod_devicetable.h> for now.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # zorro
Link: https://patch.msgid.link/41400e323be8640702b906d04327e833c5bdaf4a.1782808461.git.u.kleine-koenig@baylibre.com
[Drop "MOD" from the header guards]
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

ata: libata-scsi: limit simulated SCSI command copy to response length

The function ata_scsi_rbuf_fill() is used to copy the response of
emulated SCSI commands from ata_scsi_rbuf to the SCSI command's
scatterlist.

Currently, sg_copy_from_buffer() is called with the size argument
set to ATA_SCSI_RBUF_SIZE (2048 bytes). Since ata_scsi_rbuf is
zeroed out before the simulation actor is invoked, copying the
full buffer size causes the remainder of the SCSI command's
transfer buffer (beyond the actual response length 'len') to be
overwritten with zeroes. This clobbers any pre-existing sentinel
values or data in the caller's buffer tail, even though the
correct residual count is reported via scsi_set_resid().

Fix this by passing the actual response length 'len' as the copy
size to sg_copy_from_buffer(), ensuring that the tail of the
caller's buffer remains untouched. Also, add a defensive check
to ensure that the actor does not return a length exceeding the
static buffer capacity. If this occurs, trigger a WARN_ON(),
fail the command with an aborted command error, and return
immediately without copying any data.

The fix was tested by invoking an SCSI SG_IO INQUIRY on
an ATA disk on vanilla build, and build with the fix. Confirmed
that the input buffer's tail end remains unmodified with the fix.

Fixes: 5251ae224d8d ("ata: libata-scsi: Return residual for emulated SCSI commands")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Karuna Ramkumar <rkaruna@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

ata: pata_pxa: Fix DMA channel leak on probe error

When dmaengine_slave_config() fails, the DMA channel acquired by
dma_request_chan() is not released before returning the error,
leaking the channel reference.

Fix by adding dma_release_channel() in the error path.

The ata_host_activate() error path already correctly releases the
DMA channel.

Cc: stable@vger.kernel.org
Fixes: 88622d80af82 ("ata: pata_pxa: dmaengine conversion")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

ata: sata_gemini: unwind clocks on IDE pinctrl errors

gemini_sata_bridge_init() prepares and enables both SATA PCLKs, then
disables them again while keeping the clocks prepared for later bridge
start and stop operations. If gemini_setup_ide_pins() fails after that,
gemini_sata_probe() returns directly and skips the existing
out_unprep_clk unwind path.

Route the IDE pinctrl failure through out_unprep_clk so the clocks
prepared by gemini_sata_bridge_init() are unprepared before probe
fails.

Fixes: d872ced29d5f ("ata: sata_gemini: Introduce explicit IDE pin control")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

ata: libata-core: Reject an invalid concurrent positioning ranges count

ata_dev_config_cpr() takes the number of range descriptors from buf[0]
of the concurrent positioning ranges log (up to 255), which the device
reports independently of the log size in the GPL directory. The count is
then walked at a fixed 32-byte stride in two places with no bound: the
log read here, and the INQUIRY VPD page B9h emitter, which writes one
descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device
reporting a count larger than its own log overflows the read buffer (up
to 7704 bytes past a 512-byte slab), and a count above 62 overflows the
response buffer on the emit side.

Bound the count once, on probe, against both the log the device returned
and the number of descriptors the VPD B9h response buffer can hold
(ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range
count with a warning; this keeps the emitter in bounds with no separate
change there.

Suggested-by: Damien Le Moal <dlemoal@kernel.org>
Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
Fixes: c745dfc541e7 ("libata: fix reading concurrent positioning ranges log")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD

The PNY CS900 1TB SSD (Phison PS3111-S11, DRAM-less) drops off the bus
after entering Device-Initiated Slumber during idle. With the default
med_power_with_dipm policy the link goes down (SStatus 1 SControl 300)
and does not recover, forcing the filesystem read-only. Forcing
max_performance keeps the link stable across prolonged idle.

Add a NOLPM quirk so link power management is disabled for this drive
specifically, leaving it intact for other devices on the host.

Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

Merge tag 'bpf-fixes' of git://git./linux/kernel/git/bpf/bpf

Pull BPF fixes from Daniel Borkmann:

 - Initialize task local storage before fork bails out to free the task
   (Jann Horn)

 - Fix insn_aux_data leak on verifier error path (KaFai Wan)

 - Reject BPF inode storage map creation when BPF LSM is uninitialized
   (Matt Bobrowski)

 - Mask pseudo pointer values in verifier logs when pointer leaks are
   not allowed (Nuoqi Gui)

 - Harden BPF JIT against spraying via IBPB flush (Pawan Gupta)

 - Reject a skb-modifying SK_SKB stream parser since the latter is only
   meant to measure the next message (Sechang Lim)

 - Fix bpf_refcount_acquire to reject refcounted allocation arguments
   with a non-zero fixed offset (Yiyang Chen)

* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
  bpf: Prefer dirty packs for eBPF allocations
  bpf: Prefer packs that won't trigger an IBPB flush on allocation
  bpf: Skip redundant IBPB in pack allocator
  bpf: Restrict JIT predictor flush to cBPF
  x86/bugs: Enable IBPB flush on BPF JIT allocation
  bpf: Support for hardening against JIT spraying
  bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
  bpf,fork: wipe ->bpf_storage before bailouts that access it
  bpf: Fix insn_aux_data leak on verifier err_free_env path
  selftests/bpf: Cover pseudo-BTF ksym log masking
  bpf: Mask pseudo pointer values in verifier logs
  selftests/bpf: Cover refcount acquire node offsets
  bpf: Reject offset refcount acquire arguments
  selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser
  bpf, sockmap: reject a packet-modifying SK_SKB stream parser
  selftests/bpf: don't modify the skb in the strparser parser prog

Merge tag 'vfio-v7.2-rc2' of https://github.com/awilliam/linux-vfio

Pull VFIO fixes from Alex Williamson:
 "Mostly straightforward fixes here, inconsistent runtime PM handling
  due to global device policies, bitfield races, unwind path gaps,
  teardown ordering, and a misplaced library flag.

   - Fix racy bitfield updates in vfio-pci-core and the mlx5 vfio-pci
     variant driver with a binary split between setup/release and
     runtime modified flags. These were noted across several Sashiko
     reviews as pre-existing issues (Alex Williamson)

   - Fix runtime PM inconsistency where the vfio-pci driver module_init
     could modify the idle PM policy of existing devices through globals
     managed in vfio-pci-core, leading to unbalanced runtime PM
     operations (Alex Williamson)

   - Restore mutability of writable vfio-pci module options by further
     pulling policy globals out of vfio-pci-core, to instead be latched
     per device at device init. Provide visibility of the per device
     latched values through debugfs (Alex Williamson)

   - Fix missing VGA arbiter uninit callback in unwind path (Alex
     Williamson)

   - Reorder device debugfs removal before device_del() to avoid gap
     where debugfs is available with stale devres pointers (Alex
     Williamson)

   - Move UUID library linking flag from vfio selftest Makefile into
     libvfio.mk to avoid exposing such dependencies when linking with
     KVM selftests (Sean Christopherson)"

* tag 'vfio-v7.2-rc2' of https://github.com/awilliam/linux-vfio:
  vfio: selftests: Add luuid to libvfio.mk's list of libraries, not to the Makefile
  vfio/pci: Expose latched module parameter policy in debugfs
  vfio: Remove device debugfs before releasing devres
  vfio/pci: Latch all module parameters per device
  vfio/mlx5: Fix racy bitfields and tighten struct layout
  vfio/pci: Fix racy bitfields and tighten struct layout
  vfio/pci: Release the VGA arbiter client on register_device() failure
  vfio/pci: Latch disable_idle_d3 per device

Merge tag 'net-7.2-rc2' of git://git./linux/kernel/git/netdev/net

Pull networking fixes from Paolo Abeni:
 "Including fixes from netfilter and batman-adv.

  Current release - new code bugs:

   - netfilter: cthelper: cap to maximum number of expectation per master

  Previous releases - regressions:

   - netpoll: fix a use-after-free on shutdown path

   - tcp: restore RCU grace period in tcp_ao_destroy_sock

   - ipv6: fix NULL deref in fib6_walk_continiue() on multi-batch dump

   - batman-adv: dat: ensure accessible eth_hdr proto field

   - eth:
      - virtio_net: disable cb when NAPI is busy-polled
      - lan743x: Initialize eth_syslock spinlock before use

  Previous releases - always broken:

   - netfilter:
      - nft_set_pipapo: don't leak bad clone into future transaction

   - sched:
      - sch_teql: Introduce slaves_lock to avoid race condition and UAF
      - replace direct dequeue call with peek and qdisc_dequeue_peeked

   - sctp: add INIT verification after cookie unpacking

   - tipc: fix out-of-bounds read in broadcast Gap ACK blocks

   - seg6: validate SRH length before reading fixed fields

   - eth:
      - mlx5e: fix use-after-free of metadata_dst on RX SC delete
      - enetc: check the number of BDs needed for xdp_frame
      - fbnic: don't cache shinfo across skb realloc"

* tag 'net-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (58 commits)
  net/mlx5: HWS, fix matcher leak on resize target setup failure
  net/sched: hhf: clear heavy-hitter state on reset
  net/sched: dualpi2: clear stale classification on filter miss
  net/sched: act_bpf: use rcu_dereference_bh() to read the filter
  selftests: drv-net: tso: don't touch dangerous feature bits
  cxgb4: Fix decode strings dump for T6 adapters
  virtio_net: disable cb when NAPI is busy-polled
  sctp: fix addr_wq_timer race in sctp_free_addr_wq()
  selftests: net: bump default cmd() timeout to 20 seconds
  bridge: stp: Fix a potential use-after-free when deleting a bridge
  net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
  net: gianfar: dispose irq mappings on probe failure and device removal
  net: lan743x: Initialize eth_syslock spinlock before use
  net: libwx: fix VMDQ mask for 1-queue mode
  net: airoha: fix max receive size configuration
  fsl/fman: Free init resources on KeyGen failure in fman_init()
  netfilter: nftables: restrict checkum update offset
  netfilter: nftables: restrict linklayer and network header writes
  netfilter: nfnetlink_queue: restrict writes to network header
  netfilter: nft_fib: reject fib expression on the netdev egress hook
  ...

Merge tag 'hwmon-for-v7.2-rc2' of git://git./linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:

 - adm1275: Detect coefficient overflow, and prevent reading
   uninitialized stack

 - aspeed-g6-pwm-tach: Guard fan RPM calculation against divide-by-zero

 - asus_atk0110: Check package count before accessing element

 - ltc4283: fix malformed table docs build error

 - occ: Unregister sysfs devices outside occ lock to avoid lockdep
   warning

 - pmbus core: Fix passing events to regulator core, and honor
   vrm_version in pmbus_data2reg_vid()

 - w83627hf: Remove VID sysfs files on error and remove

 - w83793: remove vrm sysfs file on probe failure

 - Various: Add missing 'select REGMAP_I2C' to Kconfig

* tag 'hwmon-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-zero
  hwmon: (pmbus) Fix passing events to regulator core
  hwmon: adm1275: Detect coefficient overflow
  hwmon: adm1275: Prevent reading uninitialized stack
  hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig
  hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig
  hwmon: (max1619) add missing 'select REGMAP' to Kconfig
  hwmon: (w83627hf) remove VID sysfs files on error and remove
  hwmon: (w83793) remove vrm sysfs file on probe failure
  hwmon: (asus_atk0110) Check package count before accessing element
  docs: hwmon: ltc4283: fix malformed table docs build error
  hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()
  hwmon: (occ) unregister sysfs devices outside occ lock

Merge tag 'mfd-fixes-7.2' of git://git./linux/kernel/git/lee/mfd

Pull MFD fix from Lee Jones:

 - Add MFD mailing list to MAINTAINERS

* tag 'mfd-fixes-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
  MAINTAINERS: Add a mailing list entry to MFD

Merge tag 'batadv-net-pullrequest-20260630' of https://git.open-mesh.org/batadv

Simon Wunderlich says:

====================
Here are some batman-adv bugfix, all by Sven Eckelmann:

 - fix pointers after potential skb reallocs (5 patches)

 - dat: ensure accessible eth_hdr proto field

* tag 'batadv-net-pullrequest-20260630' of https://git.open-mesh.org/batadv:
  batman-adv: dat: ensure accessible eth_hdr proto field
  batman-adv: bla: reacquire gw address after skb realloc
  batman-adv: dat: acquire ARP hw source only after skb realloc
  batman-adv: gw: acquire ethernet header only after skb realloc
  batman-adv: access unicast_ttvn skb->data only after skb realloc
  batman-adv: retrieve ethhdr after potential skb realloc on RX
====================

Link: https://patch.msgid.link/20260630134430.85786-1-sw@simonwunderlich.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

MAINTAINERS: Add a mailing list entry to MFD

This is to be included by all contributors and will be leaned on for
Sashiko's "reply to author" support.

Signed-off-by: Lee Jones <lee@kernel.org>

net/mlx5: HWS, fix matcher leak on resize target setup failure

hws_bwc_matcher_move() allocates a replacement matcher before setting it
as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
replacement matcher is not attached anywhere and is leaked.

Fix the leak by destroying the replacement matcher before returning from
the resize-target failure path.

The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.

An x86_64 allyesconfig build showed no new warnings. As we do not have a
mlx5 HWS-capable device to test with, no runtime testing was able to be
performed.

Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260629064049.3852759-1-dawei.feng@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

x86/Xen: correct commentary and parameter naming of xen_exchange_memory()

As documented in comments in struct xen_memory_exchange, the input to the
hypercall is a set of MFNs which are to be removed from the domain, plus a
set of PFNs where the newly allocated MFNs are to appear. Present comment
and parameter naming don't correctly reflect that.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <7e0c8795-cc60-4b78-8601-6a999739467a@suse.com>

Merge tag 'bootconfig-fixes-v7.2-rc1' of git://git./linux/kernel/git/trace/linux-trace

Pull bootconfig fix from Masami Hiramatsu:

 - bootconfig: Fix NULL-pointer arithmetic

   Fix undefined pointer arithmetic in xbc_snprint_cmdline() when
   probing the buffer length with NULL and size 0. Track the written
   length as a size_t instead to prevent build-time UBSan/FORTIFY_SOURCE
   failures.

* tag 'bootconfig-fixes-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()

Merge tag 'nf-26-06-30' of https://git./linux/kernel/git/netfilter/nf

Florian Westphal says:

====================
netfilter: updates for net

The following patchset contains Netfilter fixes for *net*.
Due to bug volume the plan is to make a second *net* pull request
this Friday.

1) Zero nf_conntrack_expect at allocation to prevent uninitialized data
leaks to userspace. Add missing exp->dir initialization.

2) Prevent out-of-bounds writes in nft_set_pipapo caused by inconsistent
clones during allocation failures.  Fail operations if the clone enters an
error state.  This was a day-0 bug.

3) Fix use-after-free race between ipset dump and array resizing. Protect
array pointer access with rcu_read_lock().  From Xiang Mei. Bug existed
since v4.20.

4) Validate skb_dst() exists before access in nf_conntrack_sip.
This Prevent crash when called from tc ingress or openvswitch.
From Pablo Neira Ayuso.  Bug added in 4.3 when ovs gained support
for conntrack helpers.

5) Cap the maximum number of expectations to NF_CT_EXPECT_MAX_CNT during
userspace helper policy updates.  Also from Pablo.

6) Prevent NULL pointer dereference in nft_fib on netdev egress hooks. Add
nft_fib_netdev_validate() to restrict fib expressions to appropriate
netdev hooks. Restrict nft_fib_validate() to IPv4, IPv6, and INET
protocols.  From Theodor Arsenij Larionov-Trichkine.
Bug was exposed in v5.16 when egress hooks got added.

7) Restrict nfnetlink_queue writes to network headers. Validate IP/IPv6
header length and disable extension headers or IP option modifications.
Disable bridge modification for now, its unlikely anyone is using this.

8) Restrict arbitrary writes to link-layer and network headers in nftables.
Prevent link-layer modifications from spilling into network headers.
Prevent writes to IP version and length fields.

9) Restrict L3 checksum update offset to IPv4. Else csum offset can be
used to munge arbitrary header offsets, rendering the previous change moot.

These three patches are follow-ups to a 7.1 change that disabled
header rewrite ability in unprivileged network namespaces.
unprivileged netns support is not yet enabled again here.

netfilter pull request nf-26-06-30

* tag 'nf-26-06-30' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
  netfilter: nftables: restrict checkum update offset
  netfilter: nftables: restrict linklayer and network header writes
  netfilter: nfnetlink_queue: restrict writes to network header
  netfilter: nft_fib: reject fib expression on the netdev egress hook
  netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master
  netfilter: nf_conntrack_sip: validate skb_dst() before accessing it
  netfilter: ipset: fix race between dump and ip_set_list resize
  netfilter: nft_set_pipapo: don't leak bad clone into future transaction
  netfilter: nf_conntrack_expect: zero at allocation time
====================

Link: https://patch.msgid.link/20260630045243.2657-1-fw@strlen.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

xfs: simplify __xfs_buf_ioend

__xfs_buf_ioend can only resubmit the buffer for asynchronous
writes, which means the retry handling xfs_buf_iowait is not needed.

Because of this can stop returning a value from __xfs_buf_ioend and
just release the buffer for async I/O that does not require retries.

Also drop the __-prefix now that the semantics are straight forward.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: fix handling of synchronous errors in xfs_buf_submit

Synchronous readers and writers already run __xfs_buf_ioend from
xfs_buf_iowait after being woken through bp->b_iowait, so we
should not call it here, which can lead to double completions.

Fixes: 4b90de5bc0f5 ("xfs: reduce context switches for synchronous buffered I/O")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: remove xfs_buf_ioend

There are two callers of xfs_buf_ioend, one of which always has the
XBF_ASYNC flag set.  Open code the logic in both callers to prepare for a
bug fix.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: improve the xfs_buf_ioend_fail calling convention

Move setting the ASYNC flag into xfs_buf_ioend_fail, assert that the
buffer is locked as expected, and drop the confusing _ioend in the
name.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: use null daddr for unset first bad log block

xlog_do_recovery_pass() may return before setting first_bad.  The caller
must distinguish that case from an error at a valid log block, including
block zero after the log wraps.

Initialize first_bad to XFS_BUF_DADDR_NULL and test it explicitly before
treating the error as a torn write.

Fixes: 7088c4136fa1 ("xfs: detect and trim torn writes during log recovery")
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Reported-by: syzbot+b7dfbed0c6c2b5e9fd34@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b7dfbed0c6c2b5e9fd34
Cc: stable@vger.kernel.org # v4.5
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: fix memory leak in xfs_dqinode_metadir_create()

If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current
code returns directly, leaking the allocated update and transaction state.
If the subsequent commit fails, the caller-owned inode reference is left
behind.

Fix this memory leak by routing the create failure path through
xfs_metadir_cancel().  For both create and commit failures, finish and
release any inode returned to the caller, mirroring the unwind pattern in
xfs_metadir_mkdir().

The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.

An x86_64 allyesconfig build showed no new warnings. Runtime validation
used kprobe fault injection during `mount -o uquota` on a metadir XFS
image. Injecting xfs_metadir_create() reproduced the old active-update path
that left mount stuck later in mount setup; after this change, the same
injection reported cancel_hits=1 and irele_hits=1. Injecting
xfs_metadir_commit() exercised the old inode-reference leak path; after
this change, it reported irele_hits=1.

Fixes: e80fbe1ad8ef ("xfs: use metadir for quota inodes")
Cc: stable@vger.kernel.org # v6.13
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: release dquot buffer after dqflush failure

xfs_qm_dqpurge() gets a locked buffer from xfs_dquot_use_attached_buf().
If xfs_qm_dqflush() fails, the error path skips xfs_buf_relse() and then
calls xfs_dquot_detach_buf(), which tries to lock the same buffer again.

Release the buffer after xfs_qm_dqflush() returns so the error path drops
the caller hold and unlocks the buffer before the dquot is detached,
matching the other dqflush callers.

Fixes: a40fe30868ba ("xfs: separate dquot buffer reads from xfs_dqflush")
Cc: stable@vger.kernel.org # v6.13+
Signed-off-by: Yingjie Gao <gaoyingjie@uniontech.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: also mark the buffer stale on verifier failure in xfs_buf_submit

We should treat the buffer that caused a shutdown the same as handling
buffers after a shutdown, so use the same stale && !DONE logic here.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

xfs: open code xfs_buf_ioend_fail in xfs_buf_submit

This better integrates with the other failure handling in xfs_buf_submit,
and prepares for a better API in xfs_buf_ioend_fail.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

bpf: Prefer dirty packs for eBPF allocations

The pack allocator only flushes predictors when reusing a dirty pack for
cBPF, eBPF allocations never trigger a flush. Currently, eBPF picks the
first free pack, which could be a clean pack. As an optimization, leaving
a clean pack for cBPF can avoid flushes.

Prefer dirty packs for eBPF and keep clean packs free for cBPF. This
mirrors the existing cBPF preference for clean packs: each program kind
prefers the pack that avoids an extra flush, and falls back to the other
kind only when no preferred pack has room. eBPF reuse of a dirty pack is
harmless since eBPF being privileged does not flush.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

bpf: Prefer packs that won't trigger an IBPB flush on allocation

Currently BPF pack allocator picks the chunks from the first available
pack. While this is okay, it naturally leads to more frequent flushes
when there are multiple packs in the system that weren't used since the
last flush.

As an optimization prefer allocating the new programs from packs that
are unused since last flush. When all packs are dirty, allocation forces
a flush and marks all packs clean.

Below are some future optimizations ideas:

  1. Currently, the "dirty" tracking is only done at the pack-level.
     Flush frequency can further be reduced with chunk-level tracking.
     This requires a new bitmap per-pack to track the dirty state.
  2. IBPB flush is done on all CPUs, even if only a single CPU ran the
     BPF program. On a system with hundreds of CPUs this could be a
     major bottleneck forcing hundreds of IPIs to deliver the flush.
     The solution is to track the CPUs where a BPF program ran, and
     issue IBPB only on those CPUs.
  3. Avoid IBPB when flush is already done at other sources (e.g.
     context switch).

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

bpf: Skip redundant IBPB in pack allocator

bpf_prog_pack_alloc() issues IBPB on all CPUs on every cBPF allocation,
even when reusing chunks from an existing pack where no new memory was
touched since the last IBPB.

Since IBPB on all CPUs is heavy, Dave Hansen suggested to track allocation
since last IBPB, and only issue IBPB at reuse for the chunks that have not
seen an IBPB since they were last freed.

Track per-pack whether an IBPB is needed via arch_flush_needed. Set it when
allocating a chunk, reset on IBPB flush. On reuse, conditionally issue the
flush. Since IBPB invalidates all BTB entries, clear the flag on all packs
after flushing.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

bpf: Restrict JIT predictor flush to cBPF

Currently predictor flush on memory reuse is done for all BPF JIT
allocations, but only cBPF programs can be loaded by an unprivileged user.
eBPF is privileged by default, and flushing predictors for all CPUs on
every eBPF reuse penalizes the common case for no security benefit.

eBPF allocations can be frequent on busy systems, only flush predictors
for cBPF programs. Trampoline and dispatcher allocations also skip the
flush as they are eBPF-only.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

x86/bugs: Enable IBPB flush on BPF JIT allocation

Enable hardening against JIT spraying when Spectre-v2 mitigations are in
use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip
enabling the IBPB flush if the BPF dispatcher is already using a retpoline
sequence.

This hardening applies only when BPF-JIT is in use. Guard the enabling
under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

bpf: Support for hardening against JIT spraying

The BPF JIT allocator packs many small programs into larger executable
allocations and reuses space within those allocations as programs are
loaded and freed. When fresh code is written into space that a previous
program occupied, an indirect jump into the new program can reuse a branch
prediction left behind by the old one.

Flush the indirect branch predictors before reusing JIT memory so that
indirect jumps into a newly written program don't reuse predictions from an
old program that occupied the same space.

Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush
static call for flushing the branch predictors on JIT memory reuse.
Architectures that need a flush, can update it to a predictor flush
function. By default, its a NOP and does not emit any CALL.

Allocations larger than a pack are not covered by this flush. That is safe
because cBPF programs (the unprivileged attack surface) are bounded well
below a pack size. Issue a warning if this assumption is ever violated
while the flush is active.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

net/sched: hhf: clear heavy-hitter state on reset

HHF reset does not clear the classifier state used to identify heavy
hitters.  Packets after reset can therefore be scheduled using flow
history from before the reset.

The reset operation should return the qdisc to an empty state.

Clear the heavy-hitter classifier tables when HHF is reset.

Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

xenbus: reject unterminated directory replies

split_strings() walks each directory entry with strlen(). Although the
transport adds a terminator after the reply buffer, a malformed reply
without a final NUL inside its advertised length would let that walk
cross the protocol payload boundary.

Reject such replies before counting the strings. Report the protocol
violation once and return -EIO to the caller.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260626223738.43742-1-alhouseenyousef@gmail.com>

net/sched: dualpi2: clear stale classification on filter miss

DualPI2 leaves previous classification state attached to an skb when
filter classification returns no match.  The enqueue path can then act
on stale state from an earlier classification attempt.

A filter miss should fall back to the default class without reusing old
per-packet classification data.

Initialize the classification result to CLASSIC before running the
classifier.  Explicit L4S, priority, and successful filter
classification can still override that default.

Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

xen/gntalloc: validate grant count before allocation

gntalloc_ioctl_alloc() allocates the grant-id array before checking
whether the requested count fits within the global grant limit. Counts
above that limit cannot succeed, so reject them before the
user-controlled allocation reaches kcalloc().

Use a subtraction-based check while holding gref_mutex so adding the
requested count cannot wrap. Also cast the count before advancing the
per-file index so the page-size multiplication is performed in 64-bit
arithmetic.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com>

xen/gntalloc: make grant counters unsigned

The module limit and current allocation count cannot validly be
negative. Give both variables unsigned types so their representation
matches the u32 grant count supplied through the ioctl and negative
module parameter values are rejected by parameter parsing.

This also prepares the limit check for overflow-safe unsigned
arithmetic.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260626223805.43781-2-alhouseenyousef@gmail.com>

xen/front-pgdir-shbuf: free grant reference head on errors

grant_references() allocates a private grant-reference head before
claiming references for the page directory and, for guest-owned buffers,
the data pages. The success path frees the remaining head, but claim
failures and grant_refs_for_buffer() errors return immediately.

Unwind through a common exit path so the private grant-reference head is
released even when granting fails part-way through setup. The caller
still tears down any references already stored in buf->grefs.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260629160517.29340-1-alhouseenyousef@gmail.com>

xen/gntdev: fix error handling in ioctl

When gntdev_ioctl_map_grant_ref() fails to copy the operation result
back to userspace after successfully adding the mapping to the list,
the error path returns -EFAULT without releasing the reference
acquired by gntdev_alloc_map(). The mapping remains in priv->maps
with a refcount of 1, causing a memory leak and a dangling list
entry.

Additionally, gntdev_add_map() may modify map->index to avoid overlap
with existing mappings. Therefore, the index returned to userspace
must be obtained after gntdev_add_map() completes.

Fix this by holding the mutex across gntdev_add_map(), retrieving
the correct index, and copy_to_user(). If copy_to_user() fails,
remove the mapping from the list and release the reference while
still holding the lock.

Cc: stable@vger.kernel.org
Fix these issues by properly handling all error cases.

Fixes: 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex")
Fixes: 68b025c813c2 ("xen-gntdev: Add reference counting to maps")

Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260622112541.38194-1-vulab@iscas.ac.cn>

xen: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files

While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.

This is a completely mechanical patch (done with a simple "sed -i"
statement).

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260619114547.159637-1-thuth@redhat.com>

xen/pvcalls: bound backend response req_id before indexing rsp[]

pvcalls_front_event_handler() takes req_id directly from the
backend-supplied ring response and uses it to index the fixed-size
bedata->rsp[] array for a memcpy() and a store, with no range check. A
malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING
and drive an out-of-bounds write past the bedata allocation.

req_id was also declared int while the wire field rsp->req_id is u32, so
a range check on the signed value alone is insufficient: a backend
req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING
test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single
bound covers both ends.

A backend that sends an out-of-range req_id has violated the wire
protocol, so rather than silently dropping the response, log once and
stop trusting the backend: set bedata->disabled. The event handler then
ignores further responses, and the request paths that wait for a
response return -EIO instead of blocking forever. This mirrors the
fatal-error handling xen-netback uses (xenvif_fatal_tx_err()).

The pvcalls frontend currently trusts its backend, so this is not a
classic-Xen security issue, but it matters for hardening PV frontends
against malicious backends (confidential and disaggregated deployments).

Fixes: 2195046bfd69 ("xen/pvcalls: implement socket command and handle events")
Suggested-by: Juergen Gross <jgross@suse.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260617014149.2647404-1-michael.bommarito@gmail.com>

pinctrl: meson: restore non-sleeping GPIO access

Commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
sleeping") set gpio_chip.can_sleep = true to work around
gpio-shared-proxy holding a spinlock across a sleeping pinctrl config
path. That locking bug is now fixed in the shared-proxy itself ("gpio:
shared-proxy: always serialize with a sleeping mutex"), so the
controller-wide workaround is no longer needed; the meson GPIO
controller does not sleep.

meson_gpio_get/set/direction_* access MMIO through regmap. The
regmap_mmio bus uses fast I/O (spinlock) locking, so these value
callbacks do not contain sleeping operations. Since gpio_chip.can_sleep
describes the get/set value path, restore can_sleep = false.

Marking the controller sleeping also broke atomic value consumers such
as w1-gpio (1-Wire bitbang): w1_io.c runs its read time slot under
local_irq_save() and uses the non-cansleep gpiod_set_value() /
gpiod_get_value(), which with can_sleep=true trigger WARN_ON(can_sleep)
in gpiolib on every transferred bit (from w1_gpio_write_bit() /
w1_gpio_read_bit() via w1_reset_bus() and w1_search()). The printk and
stack dump inside the IRQs-off, microsecond-scale time slot destroy the
bit timing, so reset/presence detection and ROM search fail: the bus
master registers but w1_master_slave_count stays at 0 and no devices
are found. Verified on an Amlogic A113X board (DS18B20 on GPIOA_14):
with can_sleep restored to false the warnings are gone and the sensor
is detected and read again.

This must not be applied or backported without the shared-proxy locking
fix above; otherwise the original Khadas VIM3 splat returns on boards
that genuinely share a meson GPIO.

Fixes: 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping")
Link: https://lore.kernel.org/all/20260105150509.56537-1-bartosz.golaszewski@oss.qualcomm.com/
Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260625115718.1678991-3-v@baodeep.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe

Out of memory situation on driver's probe is expected to be reported to
the driver's framework with a proper -ENOMEM error code.

Fixes: 35570ac6039e ("gpio: add GPIO driver for the Timberdale FPGA")
Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
Link: https://patch.msgid.link/20260630145148.4081967-1-vz@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Merge tag 'probes-fixes-v7.2-rc1' of git://git./linux/kernel/git/trace/linux-trace

Pull probes fixes from Masami Hiramatsu:
 "fprobe fixes and spelling typos:

   - Fix NULL pointer dereference in fprobe_fgraph_entry(). Prevent
     general protection faults by checking shadow-stack reservation
     bounds. Skip mid-flight registered fprobes that were not counted
     during sizing.

  eprobe: fix string pointer extraction

   - Correct the casting of string pointers read from the ringbuffer to
     prevent truncation of base event pointer variables when
     dereferencing FILTER_PTR_STRING fields.

  tracing/probes: clean up argument parsing and BTF helper logic

   - Make the $ prefix mandatory for comm access: Require the $ prefix
     for special fetcharg variables like $comm and $COMM, preventing
     naming conflicts with regular BTF-based event fields.

   - Fix double addition of offset for @+FOFFSET: Clear the temporary
     offset variable after setting the FETCH_OP_FOFFS instruction to
     avoid applying the offset multiple times.

   - Remove WARN_ON_ONCE from parse_btf_arg: Prevent triggering a kernel
     warning via user-space input when creating a kprobe event on a raw
     address.

   - Fix typo in a log message: Correct a spelling error ("$-valiable")
     in trace probe log messages.

  samples/trace_events: improve error checking

   - Validate the thread pointer returned from kthread_run() in the
     trace events sample code to properly handle thread creation
     failures"

* tag 'probes-fixes-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  tracing/probes: Make the $ prefix mandatory for comm access
  tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()
  tracing/probes: Fix double addition of offset for @+FOFFSET
  tracing: eprobe: read the complete FILTER_PTR_STRING pointer
  tracing/events: Fix to check the simple_tsk_fn creation
  tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg
  tracing: probes: fix typo in a log message

net/sched: act_bpf: use rcu_dereference_bh() to read the filter

tcf_bpf_act() can run from the tc egress path, which holds only
rcu_read_lock_bh(), but reads prog->filter with rcu_dereference() and
trips lockdep:

  WARNING: suspicious RCU usage
  net/sched/act_bpf.c:47 suspicious rcu_dereference_check() usage!
  1 lock held by syz.2.1588/12756:
   #0: (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit net/core/dev.c:4792
   tcf_bpf_act+0x6ae/0x940 net/sched/act_bpf.c:47
   tcf_classify+0x6e4/0x1080 net/sched/cls_api.c:1860
   sch_handle_egress net/core/dev.c:4545 [inline]
   __dev_queue_xmit+0x2185/0x2c00 net/core/dev.c:4808
   packet_sendmsg+0x3dfa/0x5120 net/packet/af_packet.c:3114

The other tc actions and cls_bpf already use rcu_dereference_bh() here.
Do the same.

Fixes: 1f211a1b929c ("net, sched: add clsact qdisc")
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Link: https://patch.msgid.link/20260629154112.1164986-1-rhkrqnwk98@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: drv-net: tso: don't touch dangerous feature bits

query_nic_features() detects which offloads depend on tx-gso-partial
by enabling everything, turning tx-gso-partial off, and seeing which
active features drop out. Enabling all hw features is dangerous:
we may end up enabling rx-fcs and loopback for example. For the
ice driver we end up getting into problems with feature dependencies
so the cleanup isn't successful either, and the test exits with
rx-fcs and loopback enabled.

Scope the feature probing just to segmentation bits.

Fixes: 266b835e5e84 ("selftests: drv-net: tso: enable test cases based on hw_features")
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260629233923.2151144-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

cxgb4: Fix decode strings dump for T6 adapters

Depending on the value of chip_version, the correct decode set is selected.
However, the subsequent matching with the t4 encoding type in the if-else
block results in a reassignment, which leads to the loss of support for
t6_decode as well as reinitializing of values t4_decode and t5_decode.

The component history shows that the if-else block previously used for
this purpose, as well as the execution order, was not affected by the
change.
Furthermore, it is suggested by the execution order that the scenario with
overwriting and loss of support will be implemented.

Delete the if-else block.

Fixes: 6df397539cb0 ("cxgb4: Update correct encoding of SGE Ingress DMA States for T6 adapter")
Signed-off-by: Gleb Markov <markov.gi@npc-ksb.ru>
Reviewed-by: Potnuri Bharat Teja <bharat@chelsio.com>
Link: https://patch.msgid.link/20260629130856.1168-1-markov.gi@npc-ksb.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

virtio_net: disable cb when NAPI is busy-polled

When busy-poll is active, napi_schedule_prep() returns false in
virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped.
The device may keep firing irqs until reaches virtqueue_napi_complete().
Under load (received == budget), it will lead to a large number
of spurious interrupts.

Fix it by disabling the callback at the virtnet_poll() entry.
This keeps the callback off while we poll and it is re-enabled by
virtqueue_napi_complete() when going idle.

Fixes: ceef438d613f ("virtio_net: remove custom busy_poll")
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Longjun Tang <tanglongjun@kylinos.cn>
Link: https://patch.msgid.link/20260629024230.37325-1-lange_tang@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

sctp: fix addr_wq_timer race in sctp_free_addr_wq()

sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete()
while holding addr_wq_lock. However, timer_delete() does not guarantee that
a currently running timer handler has completed.

This allows a race with sctp_addr_wq_timeout_handler(), where the handler
may still run after addr_waitq has been freed, acquire addr_wq_lock, and
access freed memory, leading to a use-after-free.

Fix this by calling timer_shutdown_sync() before taking addr_wq_lock.  This
guarantees that any in-flight timer handler has finished and prevents the
timer from being re-armed during teardown, making subsequent cleanup safe.

Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/5dc95f295bdb5c3f60e880dd9aa5112dc5c071cc.1782757874.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: net: bump default cmd() timeout to 20 seconds

We always used 5 sec as the default command timeout. But soon after
it was introduced, David effectively made us ignore the timeout
(it was passed to process.communicate() as the wrong argument).
Gal recently fixed that, but turns out the 5 sec is not enough
for a lot of tests and setups. The fix caused regressions.

In particular running reconfig commands (e.g. XDP attach) on mlx5
with 32 rings and 9k MTU, on a heavily-debug-enabled kernel takes
more than 5 sec. The XDP installation command will time out after
5 sec but since the sleeps in the kernel are non interruptible
the command finishes anyway, leaving the XDP program attached,
but with non-zero exit code. defer()ed cleanups are not installed,
breaking the environment for subsequent tests.

Since "install XDP" is a pretty normal command a "point fix"
does not seem appropriate. 32 rings is a fairly reasonable
config, too, so we should just increase the timeout to 20 sec.

There's no real reason behind the value of 20.

Fixes: 1cf270424218 ("net: selftest: add test for netdev netlink queue-get API")
Fixes: f0bd19316663 ("selftests: net: fix timeout passed as positional argument to communicate()")
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Acked-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Link: https://patch.msgid.link/20260629233348.2145841-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()

xbc_snprint_cmdline() is meant to be called twice: first with
buf=NULL, size=0 to probe the rendered length, then with a real
buffer to fill it (the standard snprintf() two-pass pattern). The
probe call makes the function compute "buf + size" (NULL + 0) and,
on every iteration, advance "buf += ret" from that NULL base and
pass the result back into snprintf().

Pointer arithmetic on a NULL pointer is undefined behavior. It is
harmless in the in-kernel callers today, but the follow-up patches
run this same code in the userspace tools/bootconfig parser at kernel
build time, where host UBSan / FORTIFY_SOURCE abort the build.

Track a running written length (size_t) instead of mutating @buf, and
only form "buf + len" when @buf is non-NULL. snprintf(NULL, 0, ...)
is itself well defined and returns the would-be length, so the
two-pass "probe then fill" usage returns identical byte counts.

Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-1-24ab72139c29@debian.org/
Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line")
Cc: stable@vger.kernel.org
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

vfio: selftests: Add luuid to libvfio.mk's list of libraries, not to the Makefile

Link to the uuid library as part of libvfio.mk instead of as only linking
it via VFIO selftests' Makefile, as the whole point of providing libvfio.mk
is to allow linking the VFIO library functionality into KVM selftests,
without KVM selftests having to know the gory details or duplicate code.

Cc: Raghavendra Rao Ananta <rananta@google.com>
Cc: David Matlack <dmatlack@google.com>
Cc: Vipin Sharma <vipinsh@google.com>
Cc: Alex Williamson <alex@shazbot.org>
Fixes: e65f1bf8a2db ("vfio: selftests: Extend container/iommufd setup for passing vf_token")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20260630212805.474418-1-seanjc@google.com
Signed-off-by: Alex Williamson <alex@shazbot.org>

tracing/probes: Make the $ prefix mandatory for comm access

Since $comm or $COMM are not event field but special fetcharg
variables to access current->comm, It should not be accessed
without '$' prefix even with typecast.

Link: https://lore.kernel.org/all/178231209724.732967.12049805699091810641.stgit@devnote2/
Fixes: 69efd863a785 ("tracing/eprobes: Allow use of BTF names to dereference pointers")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()

fprobe_fgraph_entry() sizes a shadow-stack reservation in one walk of
the per-ip fprobe list and fills it in a second walk, both under
rcu_read_lock() only. A fprobe registered on an already-live ip can
become visible between the two walks, so the fill walk processes an
exit_handler the sizing walk did not count and used runs past
reserved_words. If the sizing walk counted nothing, fgraph_data is NULL
and the first write_fprobe_header() faults:

  Oops: general protection fault, probably for non-canonical address ...
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  RIP: 0010:fprobe_fgraph_entry+0xa38/0xf10 kernel/trace/fprobe.c:167
  Call Trace:
   <TASK>
   function_graph_enter_regs+0x44c/0xa10 kernel/trace/fgraph.c:677
   ftrace_graph_func+0xc5/0x140 arch/x86/kernel/ftrace.c:671
   __kernel_text_address+0x9/0x40 kernel/extable.c:78
   arch_stack_walk+0x117/0x170 arch/x86/kernel/stacktrace.c:26
   kmem_cache_free+0x188/0x580 mm/slub.c:6378
   tcp_data_queue+0x18d/0x6550 net/ipv4/tcp_input.c:5590
   [...]
   </TASK>

The list cannot be frozen across the two walks, so skip a node that does
not fit the reservation and count it as missed.

Link: https://lore.kernel.org/all/20260619184425.3824774-1-rhkrqnwk98@gmail.com/
Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer")
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

tracing/probes: Fix double addition of offset for @+FOFFSET

Since commit 533059281ee5 ("tracing: probeevent: Introduce new argument
 fetching code") wrongly use @offset local variable during the parsing,
the offset value is added twice when dereferencing.
Reset the @offset after setting it in FETCH_OP_FOFFS.

Link: https://lore.kernel.org/all/178217905962.643090.1978577464942171332.stgit@devnote2/
Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: stable@vger.kernel.org

tracing: eprobe: read the complete FILTER_PTR_STRING pointer

For a char * element in an event, the FILTER_PTR_STRING filter type is
used. When the event occurs, a pointer is stored in the ringbuffer.

If an eprobe references such a char * element of a "base event", the
stored pointer is truncated when it's read from the ringbuffer.

$ cd /sys/kernel/tracing
$ echo 'e rcu.rcu_utilization $s:x64 $s:string' > dynamic_events
$ echo 1 > tracing_on
$ echo 1 > events/eprobes/enable
$ sleep 1
$ echo 0 > events/eprobes/enable
$ cat trace
   <idle>-0  ...: (rcu.rcu_utilization) arg1=0x4f arg2=(fault)
   <idle>-0  ...: (rcu.rcu_utilization) arg1=0x2 arg2=(fault)

The problem is in get_event_field

val = (unsigned long)(*(char *)addr);

addr points to the position in the ringbuffer where the pointer was
stored. The assignment reads only the lowest byte of the pointer.

Fix the cast to read the whole pointer. The output of the test above
is now

<idle>-0 ... arg1=0xffffffff81c7d3f3 arg2="Start scheduler-tick"
<idle>-0 ... arg1=0xffffffff81c57340 arg2="End scheduler-tick"

Link: https://lore.kernel.org/all/20260620145339.3234726-1-martin@kaiser.cx/
Fixes: f04dec93466a ("tracing/eprobes: Fix reading of string fields")
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

tracing/events: Fix to check the simple_tsk_fn creation

Sashiko pointed that this sample code does not correctly handle the
failure of thread creation because kthread_run() can return -errno.

Check the simple_tsk_fn is correctly initialized (created) or not.

Link: https://lore.kernel.org/all/178165817322.269421.3992299509400184196.stgit@devnote2/
Link: https://sashiko.dev/#/patchset/178092865666.163648.10457567771536160909.stgit%40devnote2
Fixes: 9cfe06f8cd5c ("tracing/events: add trace-events-sample")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg

Sashiko found that user can cause this WARN_ON_ONCE() easily
with adding a kprobe event based on a raw address with BTF
parameter.

Since this is not an unexpected condition, remove the
WARN_ON_ONCE().

Link: https://lore.kernel.org/all/178177265367.2059927.13789953014706792126.stgit@mhiramat.tok.corp.google.com/
Link: https://sashiko.dev/#/patchset/178165816303.269421.7302603996990753309.stgit%40devnote2
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips

Function 'mediatek_gpio_bank_probe()' registers three GPIO chips using
'devm_gpiochip_add_data()'. At this point, the chips become live and visible
to consumers. However, the IRQ domain isn't allocated and set up until
'mt7621_gpio_irq_setup()' is called after the GPIO chips setup finishes.
If a consumer requests a GPIO IRQ concurrently 'mt7621_gpio_to_irq()' can
be called and pass a NULL irq domain pointer irq_create_mapping(), that can
corrupt the mappings or cause a crash. Fix this possible problem seting up
irq domain before GPIO chips setup is performed.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://patch.msgid.link/20260626060112.2498324-4-sergio.paracuellos@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

gpio: mt7621: more robust management of IRQ domain teardown

The driver uses devm_gpiochip_add_data() to register the GPIO chips which
means the devres subsystem will unregister them only after the function
'mt7621_gpio_remove()' returns. During the window between domain destruction
and devres unregistering the GPIO chips, the chips are still fully active.
If a consumer or userspace invokes gpiod_to_irq() during this window,
'mt7621_gpio_to_irq()' can dereference the already-freed irq domain pointer.
Thus, manage the IRQ domain teardown using 'devm_add_action_or_reset()' to
guarantee it is destroyed strictly after the GPIO chips are removed.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://patch.msgid.link/20260626060112.2498324-3-sergio.paracuellos@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

gpio: mt7621: avoid corruption of shared interrupt trigger state

The bank-shared fields like 'rising' and 'falling' are modified using
non-atomic read-modify-write operations. Since every gpio chip instance
represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is
called concurrently for different IRQs on the same bank a possible overwrite
of each other's configuration is possible. Thus, protect this state with
'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip
'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://patch.msgid.link/20260626060112.2498324-2-sergio.paracuellos@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized

When CONFIG_BPF_LSM=y is set, BPF inode storage maps
(BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,
if the BPF LSM is not explicitly enabled at boot time (e.g. omitted
from the "lsm=" boot parameter), lsm_prepare() is never executed for
the BPF LSM.

Consequently, the BPF inode security blob offset
(bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at
its default compiled size of 8 bytes instead of being updated to a
valid offset past the reserved struct rcu_head (typically 16 bytes
or more).

When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE
map, bpf_inode() evaluates inode->i_security + 8. This erroneously
aliases the struct rcu_head.func callback pointer at the beginning
of the inode->i_security blob. During subsequent map element cleanup
or inode destruction, writing NULL to owner_storage clears the queued
RCU callback pointer. When rcu_do_batch() later executes the queued
callback, it attempts an instruction fetch at address 0x0, triggering
an immediate kernel panic.

Fix this by introducing a global bpf_lsm_initialized boolean flag
marked with __ro_after_init. Set this flag to true inside bpf_lsm_init()
when the LSM framework successfully registers the BPF LSM. Gate map
allocation in inode_storage_map_alloc() on this flag, returning
-EOPNOTSUPP if the BPF LSM is in turn uninitialized.

This fail-fast approach prevents userspace from allocating inode
storage maps when the supporting BPF LSM infrastructure is absent,
avoiding zombie map states.

Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes")
Reported-by: oxsignal <awo@kakao.com>
Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Link: https://lore.kernel.org/bpf/20260628201103.3624525-1-mattbobrowski@google.com

gpio: shared-proxy: always serialize with a sleeping mutex

The shared GPIO descriptor used either a mutex or a spinlock, chosen at
runtime from the underlying chip's can_sleep:

shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
... if (can_sleep) mutex_lock(); else spin_lock_irqsave();

can_sleep describes only the value path (->get/->set). Under the same
lock, however, the proxy may call gpiod_set_config() and
gpiod_direction_*(), which can reach pinctrl paths that take a mutex
(e.g. gpiod_set_config() -> gpiochip_generic_config() ->
pinctrl_gpio_set_config()), independent of can_sleep. On a controller
with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
the sleeping pinctrl call ran from atomic context. Reproduced on an
Amlogic A113X board with the workaround from commit 28f240683871
("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
original Khadas VIM3 report hit the same path:

BUG: sleeping function called from invalid context
  __mutex_lock
  pinctrl_get_device_gpio_range
  pinctrl_gpio_set_config
  gpiochip_generic_config
  gpiod_set_config
  gpio_shared_proxy_set_config   <- voting spinlock held
  ...
  mmc_pwrseq_simple_probe

The spinlock existed to take the value vote from atomic context, but the
vote and the (possibly sleeping) control operations share the same state
and lock, so this scheme cannot serialize config under a mutex and still
offer atomic value access. Always serialize the shared descriptor with a
mutex instead and mark the proxy a sleeping gpiochip, driving the
underlying GPIO through the cansleep value accessors: those are valid
for both sleeping and non-sleeping chips, so value access keeps working
on fast controllers, at the cost of no longer being atomic.

With every vote edge now driven through the cansleep value setter,
gpio_shared_proxy_set_unlocked() no longer needs a per-call setter: drop
its set_func callback and call gpiod_set_value_cansleep() directly. The
shared direction_output path reaches it only once the line is already an
output, so driving the value there is equivalent to re-issuing
gpiod_direction_output(), without the redundant per-edge re-assertion of
drive config and bias.

This is observable: consumers gating on gpiod_cansleep() take their
sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
emergency-restart reset handler; its normal reset is unaffected), and
consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
fail to probe. Such atomic users do not share a pin through the proxy,
whose purpose is voting on shared reset/enable lines. The same narrowing
already applies on Amlogic since that workaround, and rockchip
addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
addresses the locking error once, for every controller.

The lock type was added by commit a060b8c511ab ("gpiolib: implement
low-level, shared GPIO support"); the sleeping call under it arrived with
the proxy driver.

Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
Link: https://patch.msgid.link/20260630101545.800625-2-v@baodeep.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

bridge: stp: Fix a potential use-after-free when deleting a bridge

The three STP timers are not supposed to be armed while the bridge is
administratively down. They are synchronously deactivated when the
bridge is put administratively down and the various call sites check for
'IFF_UP' before arming them.

This check is missing from br_topology_change_detection() and it is
possible to engineer a situation in which the topology change timer is
armed while the bridge is administratively down, resulting in a
use-after-free [1] when the bridge is deleted.

Fix by adding the missing check and for good measures synchronously
shutdown the three timers when the bridge is deleted.

[1]
ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)
WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
Reported-by: Neil Young <contact@ssd-disclosure.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260629072117.497959-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF

The teql master->slaves singly linked list is not protected against
multiple writes. It can be mod'ed concurently from teql_master_xmit(),
teql_dequeue(), teql_init() and teql_destroy() without holding any list
lock or RCU protection.

zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
after an RCU grace period, but teql_master_xmit() running on another
CPU can still hold a stale pointer into the list, resulting in a
slab-use-after-free:

BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0
Read of size 8 at addr ffff888013fb0440 by task poc/332
Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512)

The fix?
Add a per-master slaves_lock spinlock that serializes all mutations of
master->slaves and the NEXT_SLAVE() links in teql_destroy() and
teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
around those updates.
Annotate master->slaves and the per-slave ->next pointer with __rcu and
use the appropriate RCU accessors everywhere they are touched:
rcu_assign_pointer() on the writer side (under slaves_lock),
rcu_dereference_protected() for the writer-side loads (also under
slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
which run under RTNL.
Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
traversal in teql_master_xmit(), so that readers either observe a fully
linked list or are deferred until the in-flight mutation completes. The two
early-return paths in teql_master_xmit() are updated to release the RCU-bh
read-side critical section before returning, since leaving it held would
disable BH on that CPU for good.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: zdi-disclosures@trendmicro.com
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260628111229.669751-1-jhs@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: gianfar: dispose irq mappings on probe failure and device removal

irq_of_parse_and_map() creates irqdomain mappings that should be
balanced with irq_dispose_mapping(). The driver never called
irq_dispose_mapping(), leaking mappings on probe failure and
device removal.

Fix by adding irq_dispose_mapping() in free_gfar_dev() and
expanding its loop from priv->num_grps to MAXGROUPS so the
error path also catches partially-initialized groups. All
irqinfo pointers are pre-initialized to NULL in gfar_of_init(),
making the NULL-guarded walk in free_gfar_dev() safe for every
scenario.

gfar_parse_group() itself is left as a simple parse function
with no resource management; cleanup is centralized in the
caller's error path.

Assisted-by: opencode:big-pickle
Fixes: b31a1d8b4151 ("gianfar: Convert gianfar to an of_platform_driver")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260626225228.427392-1-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: lan743x: Initialize eth_syslock spinlock before use

lan743x_hardware_init() calls pci11x1x_strap_get_status() during the
PCI11x1x probe sequence. That helper acquires the Ethernet subsystem
hardware lock via lan743x_hs_syslock_acquire(), which relies on
adapter->eth_syslock_spinlock to serialize access.

The spinlock is currently initialized only after the strap status is
read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized
spinlock can trip the spinlock debug check.

Fix by initializing adapter->eth_syslock_spinlock before reading the
strap status so the probe path never attempts to lock an uninitialized
spinlock.

Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G")
Cc: stable@vger.kernel.org # v6.0+
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Reviewed-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Thangaraj Samynathan<Thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20260626163218.3591486-1-arighi@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: libwx: fix VMDQ mask for 1-queue mode

In wx_set_vmdq_queues(), the VMDQ mask was not set for the devices not
supporting WX_FLAG_MULTI_64_FUNC, i.e., NGBE devices. A mask of 0 causes
__ALIGN_MASK(1, ~vmdq->mask) to return 0, which incorrectly sets
q_per_pool to 0 in wx_write_qde().

Fix the VMDQ 1-queue mask to 0x7F then ensures that __ALIGN_MASK(1,
~0x7F) correctly evaluates to 1.

Fixes: c52d4b898901 ("net: libwx: Redesign flow when sriov is enabled")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Link: https://patch.msgid.link/161F704D2C983E2C+20260626092530.551028-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: airoha: fix max receive size configuration

Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
during hardware initialization instead of updating it according to the
configured MTU. This avoids dropping incoming frames that exceed the
current MTU but could still be processed by the networking stack, which
is able to fragment the reply on the TX side (e.g. ICMP echo requests).
Move the per-port MTU configuration to the PPE egress path where it
belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
to dynamically track the maximum MTU across running interfaces sharing
the same PPE instance.
Fix the PPE MTU register addressing to pack two port entries per
register word and add WAN_MTU0 configuration for non-LAN GDM devices.

Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

fsl/fman: Free init resources on KeyGen failure in fman_init()

fman_muram_alloc() allocates initialization resources before
initializing the KeyGen block. If keygen_init() fails, the
function returns -EINVAL directly and leaves those resources
allocated. Free the initialization resources before returning
from the KeyGen failure path.

Fixes: 7472f4f281d0 ("fsl/fman: enable FMan Keygen")
Cc: stable@kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260625004834.3394389-1-haoxiang_li2024@163.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

gpio-f7188x: Add support for NCT6126D version B

The Nuvoton NCT6126D Super-I/O is available in two hardware revisions.
According to the manufacturer datasheet revision 2.4, version A reports
chip ID 0xD283, while version B reports chip ID 0xD284.

The driver currently only recognizes only the version A ID. Version B
only contains hardware fixes unrelated to the GPIO functionality, so it
can be supported by simply adding its chip ID without any other driver
changes.

Fixes: 3002b8642f01 ("gpio-f7188x: fix chip name and pin count on Nuvoton chip")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
Link: https://patch.msgid.link/20260629-gpio-f7188x-nct6126d-version-b-v1-1-a06226c02a2d@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

netfilter: nftables: restrict checkum update offset

After previous patch, writes to network header are restricted.
However, there is another way to manipulate the l3 header: The
checksum update function.

Restrict this for network header writes, only the ipv4 header is
allowed.  This needs run-time checks because BRIDGE, INET, NETDEV
families can carry l3 headers other than IP.

checksum updates to the udp/tcp (l4) headers are not restricted.

Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nftables: restrict linklayer and network header writes

Don't permit arbitrary writes to linklayer and network header data.
Several spots in network stack trust header validation performed in
ipv4/ipv6 before PRE_ROUTING hook.

For linklayer, allow writes for netdev ingress. For other hooks, only
allow link layer writes that do not spill into network header.

For network header, check the offset/length combinations:
 - changing dscp requires store at offset 0 for checsum fixups, so
 make sure ip version + length field isn't altered.
 - ip6 dscp starts directly after the version field, so make sure it
   remains 6.

Several of these checks could already be done at rule insertion time.
Risk is that this might cause ruleset load failures for existing
rulesets. With this change such writes are silently skipped and packet
passes unchanged.

Transport and inner header bases are not checked / restricted.

Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nfnetlink_queue: restrict writes to network header

nfnetlink_queue doesn't allow selective replacements of some part of the
payload, only complete replacement.
If the new data is shorter, skb is trimmed, otherwise expanded.

Add minimal validation of the new ip/ipv6 header.  Check total len
matches skb length.  Disallow ip option modifications.

IPv6 extension headers are also disabled.
IP options and exthdrs could be allowed later after validation pass or
ip option recompile.

Transport header is not checked.

Bridge modifications are rejected.  Given userspace doesn't even receive
L2 headers, use is limited and I don't think there are any users of
bridge nfnetlink_queue, let alone users that modifiy payload.

Arp isn't supported at all.

Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nft_fib: reject fib expression on the netdev egress hook

A fib expression in a netdev egress base chain dereferences nft_in(pkt),
NULL on the transmit path, causing a NULL pointer dereference at eval.
nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook
numbers are a separate enum that aliases them (NF_NETDEV_EGRESS ==
NF_INET_LOCAL_IN), so an egress chain passes validation and then faults.

Add nft_fib_netdev_validate() that limits each result/flag to the netdev
hook where the device it reads exists: the input-device cases (OIF,
OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE
with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict
nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are
not applied to another family's hooks.

Fixes: 42df6e1d221d ("netfilter: Introduce egress hook")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/netfilter-devel/ajxsjcDOnwllMfoR@strlen.de/
Signed-off-by: Theodor Arsenij Larionov-Trichkine <theodorlarionov@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master

If userspace helper policy updates sets maximum number of expectation to
zero, cap it to NF_CT_EXPECT_MAX_CNT (255) on updates too.

Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nf_conntrack_sip: validate skb_dst() before accessing it

tc ingress and openvswitch do not guarantee routing information to be
available. These subsystems use the conntrack helper infrastructure, and
the SIP helper relies on the skb_dst() to be present if
sip_external_media is set to 1 (which is disabled by default as a module
parameter).

This effectively disables the sip_external_media toggle for these
subsystems without resulting in a crash.

Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
Cc: stable@vger.kernel.org
Reported-by: Ren Wei <n05ec@lzu.edu.cn>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: ipset: fix race between dump and ip_set_list resize

The release path of ip_set_dump_do() and ip_set_dump_done() read
inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.

A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() does
not wait for them and the old array can be freed while they still index
into it, causing a use-after-free.

The dumped set itself stays pinned via set->ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().

  BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
  Read of size 8 at addr ffff88800b5c4018 by task exploit/150
  Call Trace:
   ...
   kasan_report (mm/kasan/report.c:595)
   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
   netlink_dump (net/netlink/af_netlink.c:2325)
   netlink_recvmsg (net/netlink/af_netlink.c:1976)
   sock_recvmsg (net/socket.c:1159)
   __sys_recvfrom (net/socket.c:2315)
   ...
  Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI
  KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]
  RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)
  Kernel panic - not syncing: Fatal exception

Fixes: 8a02bdd50b2e ("netfilter: ipset: Fix calling ip_set() macro at dumping")
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>
Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>

netfilter: nft_set_pipapo: don't leak bad clone into future transaction

On memory allocation failure the cloned nft_pipapo_match can enter a bad
state:
 - some fields can have their lookup tables resized while others did
   not
 - bits might have been toggled
 - scratch map can be undersized which also means m->bsize_max can be
   lower than what is required

This means that the next insertion in the same batch can trigger
out-of-bounds writes.

Furthermore, a failure in the first can result in the bad clone to
leak into the next transaction because the abort callback is never
executed in this case (the upper layer saw an error and no attempt to
allocate a transactional request was made).

Record a state for the nft_pipapo_match structure:
- NEW (pristine clone)
- MOD (modified clone with good state)
- ERR (potentially bogus content)

Then make it so that deletes and insertions fail when the clone
entered ERR state.

In case the very first insert attempt results in an error, free the
clone right away.

Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
Cc: stable@vger.kernel.org
Reported-and-tested-by: Seesee <cjc000013@gmail.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>