Commit Graph

1482109 Commits

Author SHA1 Message Date
Kumar Kartikeya Dwivedi
dbf6806dc8 selftests/bpf: Test timer field on recycled rhtab element
Exercise the rhtab special-field lifecycle with the sequence from the
original report. A bpf_for_each_map_elem() callback deletes the sole
element, then initializes and arms a timer through the callback value
pointer while it remains valid.

Use a one-element map and pin userspace and BPF execution to one CPU.
Repeated delete-and-replace cycles drain the per-CPU allocator cache, and
periodic RCU synchronization makes the deleted units available for
recycling.

After each replacement, a second BPF program calls bpf_timer_cancel()
on its value. A successful cancellation proves both that a timer-bearing
unit was recycled and that insertion preserved the timer field. Without
the fix, insertion clears that field and cancellation keeps returning
-EINVAL. A long expiration keeps the timer callback out of the test, so
the regression is detected without accessing freed memory.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904104203.345917-3-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 12:24:24 -07:00
Yuan Chen
5df46ddcb7 bpf: Preserve special fields in recycled rhtab elements
rhtab_map_update_elem() initializes special fields after obtaining an
element from bpf_mem_cache_alloc(). The allocator can return a fresh,
zeroed unit, or recycle one from its RCU-pending lists before the
registered destructor has run.

A BPF program can retain a map-value pointer after deleting its element
and initialize and arm a timer through that pointer. If the deleted unit
is recycled, check_and_init_map_value() clears the only pointer to the
timer. Neither a later deletion nor rhtab_mem_dtor() can then cancel it,
and the callback can run with its key and value pointing into freed memory.

Do not reinitialize special fields on insertion. Fresh allocator units are
already zeroed. For recycled units, the special fields are ownership state
that must remain visible to the eventual destructor. copy_map_value()
already skips those fields, matching the non-preallocated hash-map path and
the lifecycle established by commit 275c30bcee ("bpf: Don't reinit map
value in prealloc_lru_pop").

Fixes: 6905f86012 ("bpf: Allow special fields in resizable hashtab")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
[ kkd: Split out the fix and rewrote the commit log ]
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904104203.345917-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 12:24:24 -07:00
Julian Braha
6903878d46 ima: allow users to specify the pcr index with IMA_MEASURE_PCR_IDX
The IMA_MEASURE_PCR_IDX option is currently not visible in the kconfig
frontend, so it always uses its default, 10. This means that the
'range 8 14' is dead code, and users are unable to specify the pcr index
value.

In a previous discussion, Mimi explained that users should be able to use
this config option to specify the pcr index. [1]

Let's add a prompt for users to specify the pcr index, when EXPERT is
enabled.

This dead range was found by kconfirm, a static analysis tool for Kconfig.

Link: https://lore.kernel.org/all/1feff118-4afa-4b9c-86f1-271a7a88208f@gmail.com/T/#mc4efa2491b4937eb7c9e532c29ffba516a70e662 [1]
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-09-04 14:01:00 -04:00
Jiayuan Chen
5e8c349bc8 selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0
The bpf_nf test allocs a ct, sets snat and dnat with random addr and
port via bpf_ct_set_nat_info(), then looks the ct up and checks the
reply tuple against what was set.

The port comes from bpf_get_prandom_u32() and can be 0. For
bpf_ct_set_nat_info(), port 0 means "port not specified", so only the
addr is mapped and the kernel keeps the original port. The check then
compares that port with 0 and fails, which shows up as a flaky
"Test for source natting" failure in CI [1][2].

Keep the random port in 1..65535 so it is always specified.

[1] https://github.com/kernel-patches/bpf/actions/runs/33830002889/job/100893868791
[2] https://github.com/kernel-patches/bpf/actions/runs/33829976794/job/100893220999

Fixes: b06b45e82b ("selftests/bpf: add tests for bpf_ct_set_nat_info kfunc")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://lore.kernel.org/r/20260904073745.363314-1-jiayuan.chen@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 09:57:34 -07:00
Kees Cook
90feea391c drm/amd/display: Fix harmless type mismatch in allocation
While converting to kmalloc_obj() API, a type assignment mismatch was
found between the desired struct dcn42_resource_pool and the allocated
struct dcn401_resource_pool. Fix the type (it is harmless: the objects
have the same contents and size).

Signed-off-by: Kees Cook <kees@kernel.org>
---
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <siqueira@igalia.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ovidiu Bunea <ovidiu.bunea@amd.com>
Cc: Charlene Liu <Charlene.Liu@amd.com>
Cc: Leo Chen <leo.chen@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Cc: <amd-gfx@lists.freedesktop.org>
Cc: <dri-devel@lists.freedesktop.org>
2026-09-04 09:44:34 -07:00
Linus Torvalds
986c24e0fe hid-for-linus-2026090401
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEoEVH9lhNrxiMPSyI7MXwXhnZSjYFAmqa4YwACgkQ7MXwXhnZ
 SjaNsQ/9Ff0KeKgaQUZHLE47SpOlXKWQaDJmrodDkngQh+9KaZj3NgmZD5BR2Z2p
 5v/6dhs4gFoFzQtXjuR0GvDTWzu0bx1IV3IsXhqTdhQ2fLAeu8IxUL0DEOtg3lUO
 Vlf67UagvmC+K01UWkbloS3f8dEt8tg3CXyg0Uy7f23QgBFa/TbtQpXTNGlMHOqv
 G6qE1PPBqGmPI74E/5uusI8L3tw4t8A4ylHi3UcQhTxGaUGK+Ew8GCeDsIUrwrzM
 A8Um5GHdBCWZAqluT8HPnBI2wgnUR+pvda4UdqMSYkBJW2Rz1FFaOhgLkHt+azRX
 F7RhjuxcBlaZsXIaCmIZEW6rEr0QIeUPeFK6ML3uswLtFdh/yWASUMo84Ev08Z9N
 iB7qm0+S9AZSDknINAtRRcOXsOgjvug00xMf6zcUvcP66mP1Rj/PnOGb5Lqm4icp
 SiXBF+CpN0qn3h8TWG5+GvEX0AnGcmkpL0Vx7noVHJeK8Z+Yroozv+vGi1/29pxo
 ML4QEUIYV3Uj0rU1Azgd/rKiaxnizpczeJ5ViW4+ozpT4nPHjTxcz5kVsqJ6gGV3
 XTsV9YW13xgjuB0objDDeGjYRku7MtTWUfdQiKCE71a+L9nYWr5/q2mp+8QTKWqy
 /XnK5I8o2dGWhMWCPmwoqCNO/f4FGT+J2Ok6yisG8jJ/9j6Dovk=
 =a+wk
 -----END PGP SIGNATURE-----

Merge tag 'hid-for-linus-2026090401' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

Pull HID fixes from Benjamin Tissoires:

 - hid-hyperv build fixes on certain configs (Jiri Kosina)

 - HID-BPF fix and selftests now that the bpf verifier is more
   restrictive (Benjamin Tissoires)

 - Some AI detected fixes for OOB, errors and validation (Ibrahim
   Hashimov, Shen Yongchao, Wei Jie Law)

 - various device fixes (Dave Carey and Vadim Klishko)

* tag 'hid-for-linus-2026090401' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: bpf: serialize device reference release in struct_ops destroy path
  HID: rmi: fix OOB access with undersized RMI reports
  selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier
  selftests/hid: Add a test to ensure we can write fields in hid_device
  HID: bpf: mark struct hid_device as safe BPF pointer
  HID: wacom: validate report length in wacom_intuos_pro2_bt_irq
  HID: multitouch: Fix stale MT slots when contact count drops to zero
  HID: i2c-hid: Add a quirk for a Cirque I2C device.
  HID: hyperv: make pointer arithmetics understandable for FORTIFY_SOURCE
  HID: hyperv: fix build breakage with certain configs
2026-09-04 09:25:38 -07:00
Linus Torvalds
36ec09e263 sound fixes for 7.3-rc2
A collection of small fixes since 7.3-rc1.  Quite a few fixes are
 for ALSA core for issues that have been detected by the things you
 know well.  Additionally a series of hardening for runtime PM, and
 usual quirk updates, and some other misc driver fixes are included.
 
 * Core:
 - Fixes for PCM races
 - UMP parser NULL dereference fix
 - Fix error handling in rawmidi ioctl
 
 * USB- and HD-audio:
 - Implement missing runtime PM guards across multiple interfaces
 - Fix for OOB access in US-122L MIDI driver
 - Double-free fix for CAIAQ driver
 - Quirks for HD-audio Realtek & Cirrus codecs, Conexant S3-resume,
   USB Audient devices
 
 * Others:
 - Fix of logical mistakes in dummy driver mixer and selftest code
 - Lock init fix in the legacy harmony driver
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmqaiQ0OHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE+d2Q/9EnlQ0Sr+MYS81pYzxjWNSKzvwtRw5h3B8Hjo
 bBTflzPH+iD0AI5Y0HJ31wMrkhJPSDkznQ76foZiSgTTJh85LhoG9HlZlpIxdPW4
 fNS9/N28JKRZM+qTd5P7UvGbKv9hBpMAYQPkgmAiCZ5+47oQLhgBU5THpn0Mwhxo
 JpmULLjKuSGKCf+b/SY3MY+UF7CotiQL5L5uTF83JSm8T7DdjFwzUgk6YCTzc7/b
 WbuWa5TjIg6smSzCQaip8WoE/KimLJ++zKwk8tFH2mpWcNthmTdzQGosZbp7k3l5
 G01va200DdRE7ROXdkyao7jj8FSkex23NZyQmTDYMvQz9YmGMDhsDps+Aiv11hfY
 vlwGHHHuUO/gZcjrMB+JO5MXVxsFvyNOI7L0bFMAcX8BQwcVmXLujOI+B+iY/3Ut
 TMncDaaeKDbP/dGNROVFds2nO0pUsR3Fip16Xczy4lds6QQ8XaHefUIN4jzbltHc
 hkrCKGdyXuzpBKIlSag7xE7wSAWSLGgNnRkN7614cZSK8DRJpkrtef60Uc7W8hEU
 17c9cmhOlUM6C5BvIEmdyzN6Y0tKXdJaG/gz1Wlx2iMnsNyZ9zO7ZJq5c5HU+Txl
 3559GWY4sMDtm/A/aG9daMo1Rym3dqRwqdW/DvfhLXythLCA2YRTQIG5bHunGFYU
 jok+fBc=
 =uXXN
 -----END PGP SIGNATURE-----

Merge tag 'sound-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A collection of small fixes since 7.3-rc1.

  Quite a few fixes are for ALSA core for issues that have been detected
  by the things you know well. Additionally a series of hardening for
  runtime PM, and usual quirk updates, and some other misc driver fixes
  are included.

  Core:
   - Fixes for PCM races
   - UMP parser NULL dereference fix
   - Fix error handling in rawmidi ioctl

  USB- and HD-audio:
   - Implement missing runtime PM guards across multiple interfaces
   - Fix for OOB access in US-122L MIDI driver
   - Double-free fix for CAIAQ driver
   - Quirks for HD-audio Realtek & Cirrus codecs, Conexant S3-resume,
     USB Audient devices

  Others:
   - Fix of logical mistakes in dummy driver mixer and selftest code
   - Lock init fix in the legacy harmony driver"

* tag 'sound-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (23 commits)
  ALSA: caiaq: Fix potential double-free at error path
  selftests/alsa: Fix the step check for INTEGER controls
  ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G
  ALSA: rawmidi: Return the error from snd_rawmidi_input_params()
  ALSA: ump: do not touch legacy_rmidi before it exists
  ALSA: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2
  ALSA: dummy: Report a change when one capture switch channel moves
  ALSA: usb-audio: Add mixer map quirk for Audient iD24
  ALSA: hda: restore MFG widget enumeration after core split
  ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()
  ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF
  ALSA: harmony: initialize locks before requesting IRQ
  ALSA: hda/realtek: Add quirk for VAIO VJS131
  ALSA: pcm: Fix race between non-atomic ops and trigger-start
  ALSA: hda/realtek: Add quirk for Acer Predator PHN16-72
  ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 9 14ILL10
  ALSA: hda/conexant:Fix abnormal Mic/Speaker functionality on SN6140 after S3 wake-up
  ALSA: usb-audio: Guard FCP protocol transfers
  ALSA: usb-audio: Add PM guards to RME Digiface controls
  ALSA: usb-audio: Guard Scarlett2 protocol transfers
  ...
2026-09-04 09:17:05 -07:00
Linus Torvalds
3e66602704 ata fixes for 7.3-rc2
- Work around lost interrupts on Marvell 88SE61xx.
    The Marvell AHCI controller requires you to clear interrupts in the
    opposite order from what is specified in the AHCI specification in
    order to not lose interrupts (Hajo)
 
  - Do not raise UNIT ATTENTION for depopulation commands.
    The libata completion function unconditionally sets sense data with
    sense key UNIT ATTENTION (UA) for depopulation commands. The SCSI
    layer will fail a command when seeing this sense data. UA is only
    supposed to be raised if the capacity actually changed. Since these
    commands are currently only supported as passthrough commands, the
    user is expected to revalidate the device, which will detect a
    capacity change anyway. Thus drop the unconditional UA until a
    better solution has been implemented (Damien)
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQRN+ES/c4tHlMch3DzJZDGjmcZNcgUCaprYjgAKCRDJZDGjmcZN
 cj0LAQCuA58xAXmZBFIsfHysezSKBNn3ZjwuiKKwX5DYzK1fiQEAxZWAnV0fE0wQ
 8bebZXF12uoG2+PD22ZIcUxneKeyXQg=
 =qHGE
 -----END PGP SIGNATURE-----

Merge tag 'ata-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux

Pull ata fixes from Niklas Cassel:

 - Work around lost interrupts on Marvell 88SE61xx

   The Marvell AHCI controller requires you to clear interrupts in the
   opposite order from what is specified in the AHCI specification in
   order to not lose interrupts (Hajo)

 - Do not raise UNIT ATTENTION for depopulation commands

   The libata completion function unconditionally sets sense data with
   sense key UNIT ATTENTION (UA) for depopulation commands. The SCSI
   layer will fail a command when seeing this sense data. UA is only
   supposed to be raised if the capacity actually changed.

   Since these commands are currently only supported as passthrough
   commands, the user is expected to revalidate the device, which will
   detect a capacity change anyway. Thus drop the unconditional UA until
   a better solution has been implemented (Damien)

* tag 'ata-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: libata-scsi: do not raise UA for storage element depopulation and restoration
  ata: ahci: work around lost interrupts on Marvell 88SE61xx
2026-09-04 09:00:03 -07:00
Masami Hiramatsu (Google)
d7dbdd2ee0 tracing: Fix to avoid creating trace instances with duplicate names
Since commit e645535a95 ("tracing: Add option to use memmapped
memory for trace boot instance") changed trace_array_get_by_name() to
trace_array_create_systems(), enable_instances() does not reuse the
same name instance. Therefore, if an administrator mistakenly specifies
multiple `trace_instance=` options with duplicate names, all are
created but only the first is accessible via tracefs.

Check whether an instance with the same name already exists before
creating a new one, and reject duplicates with a warning.

Link: https://patch.msgid.link/178847790399.283263.5313150997200138426.stgit@devnote2
Fixes: e645535a95 ("tracing: Add option to use memmapped memory for trace boot instance")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-04 11:44:40 -04:00
Linus Torvalds
58f93a4b73 - Fix a tree connection use-after-free in smb2_tree_connect() by
balancing references across concurrent connect, disconnect, and
    session logoff paths.
 
  - Validate source and target ranges in COPYCHUNK requests before range
    locking and copy operations.
 
  - Fix an oplock break notification UAF by acquiring a connection
    reference under ksmbd_inode lock and releasing it after the
    notification work completes.
 
  - Fix the sparc build by using an unsigned int for the atomic work
    state, ensuring xchg() uses a supported four-byte operation.
 -----BEGIN PGP SIGNATURE-----
 
 iQJKBAABCgA0FiEE6NzKS6Uv/XAAGHgyZwv7A1FEIQgFAmqan48WHGxpbmtpbmpl
 b25Aa2VybmVsLm9yZwAKCRBnC/sDUUQhCP41D/4gNSDDjbGg/Du5nNlNfd7x0/Ql
 ARgdajcnTT/2rUrBkXb3hfNi7BvSHz8jShb7acnwcs9VbxF7cWMk0r+tkjpsONI9
 hwUAXiqOQNkiUJZez+29WgiVuIqNjWSB9WKDGcA7J364Vnwm4M5a8y9wZHfV9ReQ
 aXmVlNlWP6zosrXv4Ex2Eb1bUaYnB822ZrsMQBdiZireUlVUyi/MeWOIrjxt7xPJ
 /nMTJcyDNIFjJJIQMZ/LjzIzvD82QO4LP3F8rlvHD2UIMQik6m0UXF3wPUZGPMbp
 X3o/sPoZHF1KrVpOG4SR5Lvy6KHLtGDSP7bVVhw4ahdtUnyeAeHx/xo9+OKbsiBO
 E4Sji35E8ZyIZ/xHMtOfSfA74W9ia0A0olWyG/mviptJ0RD8unddJP+D/L+EAD0I
 2pQyt9YfwsXm/7FoQXzfbtyi8Z2gl5Jp+xNr6DOyzkIulsBxFOBjgqrUEaTV2/Dc
 abqnVPLo4X9zqiE0HdSNS/go2STx9iox02blZ2wBmYNxEy4X22IheXbyN+wdtn8Q
 Ts8PrE1W0DO8PjWL9TG8okRYY3tRd0AcAVffi6P+QqkRsQNRCduv0mnAsSY1EuU0
 r/M2i5RpQ+JIBLQc4C53zOaAbBCyY1MSXUCgAs1BVyyUdqtjdPJbzyzNn6FDYVPA
 HrPxSl+fmtBsH0C25A==
 =2ZL4
 -----END PGP SIGNATURE-----

Merge tag 'ksmbd-for-7.3-rc2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb

Pull smb server fixes from Namjae Jeon:

 - Fix a tree connection use-after-free in smb2_tree_connect() by
   balancing references across concurrent connect, disconnect, and
   session logoff paths.

 - Validate source and target ranges in COPYCHUNK requests before range
   locking and copy operations.

 - Fix an oplock break notification UAF by acquiring a connection
   reference under ksmbd_inode lock and releasing it after the
   notification work completes.

 - Fix the sparc build by using an unsigned int for the atomic work
   state, ensuring xchg() uses a supported four-byte operation.

* tag 'ksmbd-for-7.3-rc2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb:
  ksmbd: fix tree connection use-after-free in smb2_tree_connect()
  ksmbd: validate COPYCHUNK source and target ranges
  ksmbd: fix use-after-free in oplock break notification
  ksmbd: fix sparc build with atomic work state
2026-09-04 08:42:14 -07:00
Linus Torvalds
421066905c Probes fixes for v7.3-rc1:
- kprobes: Protect kprobe_blacklist with RCU
   . RCU-protect kprobe_blacklist and use kfree_rcu() to prevent UAF
     races during module unloading and enable safe atomic lookups.
 - tracing/probes: Fix multi-probe field use-after-free and BTF parsing
   . Multi-probe UAF fix: Duplicate field and type strings on
     trace_probe_event to prevent UAF when freeing primary probe.
   . BTF member lookup fixes:
     - Check the containing inner struct/union kflag when resolving
       anonymous members to ensure correct bitfield offset calculation.
     - Prevent unnamed bitfields from being pushed to anon_stack in
       btf_find_struct_member(), avoiding false lookup errors.
     - Fix code block indentation in get_bitoffset_of_field().
 - uprobes: Error pointer safety
   . Guard free_trace_uprobe() with IS_ERR_OR_NULL() to avoid crashing
     during automatic cleanup when an error pointer is returned.
 -----BEGIN PGP SIGNATURE-----
 
 iQFPBAABCgA5FiEEh7BulGwFlgAOi5DV2/sHvwUrPxsFAmqahXQbHG1hc2FtaS5o
 aXJhbWF0c3VAZ21haWwuY29tAAoJENv7B78FKz8bOJIH/1RuAq2y8fvfqWKwDBNG
 9CrSIMmZ0915s4LVSGQrrjNYfpj2rFYkEMsJcFo2pavKwWNyaxXFjXu8Vy9JGckx
 VFAHA52x2QaEYdwBeoo/Jd3+7Ks/3zH1XwfSILFa0PMn86/JCKHx/+5ah6Sk4vcu
 /he61Auyp6lJtvv88n95j1evCJNouU6lJ3fnvm8mNYTeLOIvPZ3qku6SsiOqNdeQ
 Ln8bcNP2Iis33PqfeydiRWv9nPog/ifH4a9WJ+fdqKA+06AHKVsfHB+fP0hxyUDp
 TS4oxKrIk6HIbEQRjgo8YcOPWurHAm0GQ2ZslgLFuWDE9rDQCtPdOYv/YzJe0ByG
 nHc=
 =hX9F
 -----END PGP SIGNATURE-----

Merge tag 'probes-fixes-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull probes fixes from Masami Hiramatsu:

 - Protect kprobe_blacklist with RCU

   RCU-protect kprobe_blacklist and use kfree_rcu() to prevent UAF races
   during module unloading and enable safe atomic lookups.

 - Fix multi-probe field use-after-free

   Duplicate field and type strings on trace_probe_event to prevent UAF
   when freeing primary probe

 - Fix probe BTF member lookup:

   Check the containing inner struct/union kflag when resolving
   anonymous members to ensure correct bitfield offset calculation

   Prevent unnamed bitfields from being pushed to anon_stack in
   btf_find_struct_member(), avoiding false lookup errors

   Fix code block indentation in get_bitoffset_of_field()

 - uprobes error pointer safety

   Guard free_trace_uprobe() with IS_ERR_OR_NULL() to avoid crashing
   during automatic cleanup when an error pointer is returned

* tag 'probes-fixes-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  kprobes: Protect kprobe_blacklist with RCU
  tracing/probes: Fix use-after-free on field name/type of events with multiple probes
  tracing/probes: Fix code indent in get_bitoffset_of_field()
  tracing/probes: Fix BTF kflag check for anonymous struct member access
  tracing/probes: Fix anon_stack check for unnamed bitfields in btf_find_struct_member
  uprobes: guard trace cleanup against error pointers
2026-09-04 08:24:09 -07:00
Linus Torvalds
65119e86fe pmdomain providers:
- mediatek: Fix Kconfig for Airoha power domains
  - qcom: Revert adding the missing power domains for Eliza
 
 cpuidle:
  - psci: Fix support for probe deferral by dropping the faux device
  - dt_idle_genpd: Free the original name allocation
 -----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCgAuFiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmqafHMQHHVsZmhAa2Vy
 bmVsLm9yZwAKCRD+JoQlc1iMKRjID/948vUtJNrC8lwohdIxMbycSq6tyDTxGVip
 HiiF8MZu6L6agpW0sNd+9LXdmcTkzIujfTsQedmcl9Xq4ZmWTND4fyOSn29QnomD
 wyCI3W19C4SKUU9sFLJGDwXam97CJD6IG0N+0S6djKEIjuAAm2F6H/BfBjVJKqIA
 Wtp2vOdy5jMJd0+U4+odPG2EqW314G/sNA0EHDgbLEizE9riyumYh/OjjSRDOfD1
 vWobP8riqxxaDj+ij8tr0r4lWpDm/cKHCRSdONdLCh8x2ozIuHtq7T+KfCeWH1q5
 mxcgVJy6hSLMP/kFoNYTL7rxq110IaNIIAqPLLz/ywpQ13TbZHKvJd7jTM0ty8xo
 GhbiiDEDGB0s7Cdo2sZV8cZ2o+DniiDa+tLg1lNUfAH0vZp+uaiqX2tVohHLvZuW
 ELyg0cljC7bNZVvp0TCB4Or0wnE2p5Dlfr2wu/ygHOerA2m7vJOIr9UxNGDtbhHJ
 OBz8rRGKJpVAN1XlOwJNcumDhtm0ipEJ7hYpOiq2LTv7vefSg1/GxuZy50rPfDKK
 4LwAiF8AomlAhcIwkkxv6odflCSzemTNGouZ3XXSh3ETExQOg+bJhqw37cBbP8bD
 BF0uPOfEM8SqNcjejuC1M1XQW3U1sHmIzRc4B8HNUJUzjBBgrxeEV2KmhrHfQtFU
 +2kq/wPO9Q==
 =QG7D
 -----END PGP SIGNATURE-----

Merge tag 'pmdomain-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

Pull pmdomain and cpuidle fixes from Ulf Hansson:
 "pmdomain providers:
   - mediatek: Fix Kconfig for Airoha power domains
   - qcom: Revert adding the missing power domains for Eliza

  cpuidle:
   - psci: Fix support for probe deferral by dropping the faux device
   - dt_idle_genpd: Free the original name allocation"

* tag 'pmdomain-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
  cpuidle: dt_idle_genpd: kfree() the original name allocation
  pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig
  cpuidle: psci: Fix support for probe deferral by dropping the faux device
  Revert "pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza"
2026-09-04 08:17:41 -07:00
Alexei Starovoitov
41e6f03658 Merge branch 'misc-bug-fixes-part-3'
Kumar Kartikeya Dwivedi says:

====================
Misc bug fixes - part 3

A set of miscellaneous fixes for bugs reported by Nicholas, batched
together again. See commit logs for details. Some of this was caught and
posted by Ning before, but AI raised some concerns, so I'm resolving
those issues and commandeering their patches now.

Changelog:
----------
v1 -> v2
v1: https://lore.kernel.org/bpf/20260904063650.3877826-1-memxor@gmail.com

 * Fix GCC-BPF failure due to missed BTF emission for a type.
====================

Link: https://patch.msgid.link/20260904084325.52250-1-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:37 -07:00
Ning Ding
9492baf853 selftests/bpf: Reject refcount acquisition after RCU unlock
Add a sleepable verifier test that loads a refcount-only local kptr in an
explicit RCU read-side critical section, ends the section, and passes the
pointer to bpf_refcount_acquire().

The loaded pointer never carries NON_OWN_REF. After RCU unlock it retains
MEM_ALLOC while becoming PTR_UNTRUSTED, which previously made the kfunc
argument check accept it as a live allocated object. Expect verification to
reject the untrusted argument instead.

Signed-off-by: Ning Ding <dingning04@gmail.com>
[ kkd: Rewrote commit log ]
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-9-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:36 -07:00
Ning Ding
7441ee8276 bpf: Reject untrusted allocated-object pointers
When the final RCU read-side critical section ends, a local kptr is demoted
to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer
to an object whose lifetime is no longer protected.

type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with
MEM_ALLOC as a live allocated object. In particular, a refcount-only local
kptr never carries NON_OWN_REF, so it still passes the
bpf_refcount_acquire() argument check after RCU protection ends. The kfunc
can then dereference NULL or stale memory.

Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since
type_is_non_owning_ref() is based on the same predicate, graph kfunc
arguments obey the same live-object requirement. Fault-protected reads of
the demoted pointer remain valid: writes are already rejected, and read
fixups use bpf_may_fault_on_deref() rather than this predicate.

Fixes: 1b12171533 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Ning Ding <dingning04@gmail.com>
[ kkd: Rewrote commit log ]
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-8-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:36 -07:00
Kumar Kartikeya Dwivedi
6668ed271e selftests/bpf: Reject graph kptr use after RCU unlock
Add a sleepable verifier test that loads a graph-node local kptr in an
explicit RCU read-side critical section, then passes its node to
bpf_rbtree_remove() after the section ends.

Before the verifier fix, the stale NON_OWN_REF flag makes the node look like
a live borrowed reference and the program is accepted. After the fix, the
pointer is demoted without NON_OWN_REF and the graph kfunc argument is
rejected.

Also exercise a graph kptr loaded while a spin lock provides implicit RCU
protection. The pointer must be invalidated when the lock is released, which
guards the required ordering between non-owning-reference invalidation and
RCU demotion.

Update the existing fault-protected load test state description. The
post-unlock pointer no longer carries NON_OWN_REF, but remains readable
because the load is rewritten to use BPF_PROBE_MEM.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-7-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:36 -07:00
Kumar Kartikeya Dwivedi
cd6f72d7f3 bpf: Clear NON_OWN_REF after RCU protection ends
A local kptr load of an object containing a graph node is marked MEM_RCU
and NON_OWN_REF while protected by RCU. When the last RCU read-side critical
section ends, invalidate_rcu_protected_refs() removes MEM_RCU and marks the
pointer PTR_UNTRUSTED, but leaves NON_OWN_REF set.

The stale flag lets graph kfunc argument checks continue treating the
pointer as a live borrowed reference. In particular, bpf_rbtree_remove()
can accept a pointer after its protection ended and return it as a new
owning reference, even though the object may already have been freed.

Clear NON_OWN_REF when an RCU-protected pointer is demoted. A spin lock also
provides implicit RCU protection, so invalidate non-owning references before
demoting RCU-protected pointers when releasing the lock. Otherwise the
demotion would clear the flag before invalidate_non_owning_refs() can find
and invalidate those aliases.

The demoted pointer remains available for fault-protected reads. Exempt such
reads from the allocated-object reference-state assertion; writes through a
fault-prone pointer are already rejected, and bpf_may_fault_on_deref() makes
the surviving loads use BPF_PROBE_MEM.

Fixes: 1b12171533 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-6-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:36 -07:00
Ning Ding
2edd833946 selftests/bpf: Test borrowed refcount acquisition nullability
Add verifier coverage for the distinction between owning and borrowed
arguments to bpf_refcount_acquire().

An owning pointer returned by bpf_obj_new() must continue producing a
non-NULL result without an extra check. An RCU-loaded local kptr is only
borrowed, so a checked result must load successfully while passing an
unchecked result to bpf_obj_drop() must be rejected as possibly NULL.

Use a sleepable syscall program for the borrowed cases so the explicit RCU
critical section is what permits the local kptr load. Without the verifier
fix, the unchecked case is incorrectly accepted. With it, the verifier
rejects the possibly NULL argument.

Signed-off-by: Ning Ding <dingning04@gmail.com>
[ kkd: Rewrote commit log ]
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-5-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:36 -07:00
Ning Ding
dc36739e5c bpf: Keep refcount_acquire nullable for borrowed RCU kptrs
bpf_refcount_acquire() is fallible for a borrowed reference because the
object may have reached a zero refcount. The verifier therefore keeps
KF_RET_NULL on the return value unless the argument is an owning reference.

An RCU-protected load of a local kptr is marked MEM_ALLOC, but it only
receives NON_OWN_REF when the pointee contains a graph node. A refcounted
object without a graph node consequently looks like an owning reference
even though the loaded register has no acquired reference state. If the
program drops the last real reference while remaining in the RCU critical
section, refcount_inc_not_zero() returns NULL while the verifier treats the
result as non-NULL.

Only classify the argument as owning when it is backed by a verifier-tracked
reference. This retains the non-NULL return for pointers from bpf_obj_new(),
bpf_kptr_xchg(), or an earlier successful acquisition, while requiring a
NULL check for borrowed RCU kptrs.

Fixes: 1b12171533 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Ning Ding <dingning04@gmail.com>
[ kkd: Rewrote commit log ]
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-4-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:35 -07:00
Kumar Kartikeya Dwivedi
17487b31f4 selftests/bpf: Reject non-percpu values in percpu kptr fields
Add verifier coverage for the two ways a non-percpu pointer can be stored
in a __percpu_kptr field: a program-BTF local allocation returned by
bpf_obj_new(), and a referenced kernel-BTF task_struct pointer.

Without the verifier fix, both programs are unexpectedly accepted and the
negative tests fail. Requiring MEM_PERCPU makes both programs fail
verification with the expected invalid-kptr diagnostic.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-3-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:35 -07:00
Kumar Kartikeya Dwivedi
048029ba1c bpf: Require MEM_PERCPU for percpu kptr stores
map_kptr_match_type() treats perm_flags as the set of register type flags
that a kptr field permits. Adding MEM_PERCPU to that set for
BPF_KPTR_PERCPU does not require the source register to carry it, however.
The subset test consequently accepts both a plain bpf_obj_new() allocation
and a referenced kernel pointer into a __percpu_kptr map field.

Loads from the field are always marked MEM_PERCPU. Consumers then treat the
stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer
helpers relocate it, and map teardown selects the per-CPU free path. A plain
allocation can therefore provide an arbitrary kernel read/write, while a
kernel pointer can be relocated into an invalid address or sent through a
missing destructor.

Require the source MEM_PERCPU flag to match the destination field kind.
This preserves valid bpf_percpu_obj_new() stores and rejects both the
program-BTF and kernel-BTF variants.

Fixes: 36d8bdf75a ("bpf: Add alloc/xchg/direct_access support for local percpu kptr")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260904084325.52250-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04 07:58:35 -07:00
Ju Nan
d31fbbade4 irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout
HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose
timeout argument is in milliseconds, not microseconds:

  atomic_delay += HWSPINLOCK_RETRY_DELAY_US;
  if (atomic_delay > to * 1000)
          return -ETIMEDOUT;

So stm32mp_exti_set_type() asks for a 1 second timeout where the comment
next to the macro says it wants 1 millisecond. The semaphore is polled
with udelay() from a section that holds chip_data->rlock, a
raw_spinlock_t, so preemption stays disabled for the whole wait on every
configuration, PREEMPT_RT included.

The hwspinlock core documents this explicitly:

  If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) the
  timeout is handled with busy-waiting delays, hence shall not exceed
  few msecs.

Fixes: 5257169ade ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API")
Signed-off-by: Ju Nan <junan76@163.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Radu Rendec <radu@rendec.net>
Reviewed-by: Antonio Borneo <antonio.borneo@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260821024756.24927-2-junan76@163.com
2026-09-04 16:19:04 +02:00
caina
e67091609c Revert "irqchip/mbigen: Fix mbigen node address layout"
This reverts commit 6be6cba9c4.

Commit 6be6cba9c4 ("irqchip/mbigen: Fix mbigen node address layout")
appears to cause a regression on Hi1616.

On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both
behind mbigen-v2.  Port 0 works; port 1 cannot pass any traffic.

Their interrupt pins fall on different mbigen nodes:

  enahisic2i0: pins 1152-1198 -> all in node 9
  enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246)

  (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10)

/proc/interrupts shows the break happens exactly at the node boundary:

  enahisic2i1-rx0  pin 1200  count 102   <- node 9
  enahisic2i1-rx5  pin 1215  count   1   <- node 9, last pin
  enahisic2i1-tx5  pin 1216  count   0   <- node 10, first pin
  enahisic2i1-rx6  pin 1218  count   0   <- node 10
  ...all node 10 pins stay at zero.

Port 0 (entirely node 9) is unaffected.  Reverting the commit restores
normal operation.

The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000)
and collides with node 10, so node 10+ gets shifted by 0x1000.

But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never
multiplies by the node ID:

    *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET;  /* 0xa000 */

Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af
(168 bytes).  Node 10's registers are:

    TYPE: 0xa000-0xa00f  (16 B)   overlaps CLEAR by 8 B (0xa008-0xa00f)
    VEC:  0xa200-0xa3ff  (512 B)  no overlap with CLEAR

Shifting the whole page moves VEC from 0xa200 to 0xb200.  The hardware
reads the event ID from the fixed silicon address 0xa200 on interrupt
firing, but software wrote it to 0xb200 -- so the hardware gets an
uninitialised value and the interrupt is lost.

The only real overlap is 8 bytes of TYPE.  It can only trigger when a
single mbigen instance has devices on both node 1 (CLEAR 0xa008) and
node 10 (TYPE 0xa008).  On Hi1616 those nodes are on separate mbigen
instances, so it never triggers.

Fixes: 6be6cba9c4 ("irqchip/mbigen: Fix mbigen node address layout")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: caina <caina@uniontech.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Yipeng Zou <zouyipeng@huawei.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com
2026-09-04 16:12:53 +02:00
Haiyong Sun
a2628ce4dd perf build: Add clang and rust target flags for LoongArch
Add missing CLANG_TARGET_FLAGS_loongarch and RUST_TARGET_FLAGS_loongarch
so that perf can be built with clang and enable rust cross compilation.

Cc: stable@vger.kernel.org
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Dmitrii Dolgov <9erthalion6@gmail.com>
Signed-off-by: Haiyong Sun <sunhaiyong@loongson.cn>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:45:27 +08:00
Tao Cui
9296375902 LoongArch: KVM: Fix TOCTOU race on pv_features
In kvm_loongarch_cpucfg_set_attr() the check-then-set on
kvm->arch.pv_features is lockless, so two vCPUs can race past the
validation and set different values. Add a spinlock to protect it.

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:45:13 +08:00
Zeng Chi
501514d6eb LoongArch: KVM: Validate MSI data before routing it to EIOINTC
pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as
the irq number. The MSI data comes from userspace, that either via a
KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd
and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked
against EIOINTC_IRQS.

eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the
256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and
the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value
>= 256 reads and writes memory past the end of those arrays, i.e. any
process holding a VM fd can corrupt kernel memory beyond the allocation
of loongarch_eiointc.

Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC
path is unaffected as it decodes the vector from the address and masks
it.

Cc: stable@vger.kernel.org
Fixes: 1928254c5c ("LoongArch: KVM: Add irqfd support")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:45:13 +08:00
Zeng Chi
27a9bfee3b LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY
kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether
a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE,
only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every
other change. But the generic code allocates a zeroed memslot for every
change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update,
e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active
memslot has arch.flags == 0.

With both flags clear, fault_supports_huge_mapping() falls through to
the alignment check on the HVA range alone, which no longer verifies
that the GPA and HVA have the same offset within a PMD. A memslot that
was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset
mismatch can then be mapped with PMD entries on read faults, and since
kvm_map_page() aligns the gfn and the pfn independently, the guest ends
up accessing the wrong host pages, exactly the "d -> f, e -> g" case
described in the comment above the check.

Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY,
as the GPA, HVA and size are guaranteed to be unchanged for that case.

Cc: stable@vger.kernel.org
Fixes: 7ab6fb505b ("LoongArch: KVM: Optimization for memslot hugepage checking")
Tested-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:45:13 +08:00
Bibo Mao
40bdbb4bfa LoongArch: KVM: Remove unused function kvm_arch_flush_remote_tlbs_memslot()
Function kvm_arch_flush_remote_tlbs_memslot() is not called any more, so
remove this API.

Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:54 +08:00
Chaithanya Lagisetty
910132bc7d LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path
kvm_loongarch_env_init() allocates the per-CPU kvm_context (vmcs) and
kvm_loongarch_ops, registers the perf callbacks, and then registers
the IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices. If any of those device
registrations fails, the function returned the error directly, leaving
everything acquired so far in place: vmcs and kvm_loongarch_ops are
never freed, the perf callbacks stay registered, and all previously
registered KVM device operations remain registered. kvm_loongarch_init()
propagates the errors without calling kvm_loongarch_env_exit(), so
nothing else cleans up either.

Unwind the error path in reverse order of registration, so that each
failure only undoes what had actually been set up. Use the same helpers
in kvm_loongarch_env_exit() to remove the device registrations during
normal teardown as well.

Cc: stable@vger.kernel.org
Fixes: c532de5a67 ("LoongArch: KVM: Add IPI device support")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:54 +08:00
Chaithanya Lagisetty
4af2217703 LoongArch: KVM: Add unregister helpers for the KVM interrupt devices
The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that
registers their kvm_device_ops, but there is no counterpart to remove
them, so a caller that needs to undo a registration has to open-code
kvm_unregister_device_ops() with the matching device type.

Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device()
next to the existing register helpers. kvm_unregister_device_ops() is a
no-op when the corresponding device type is not currently registered.

No functional change, as there are no callers yet.

Cc: stable@vger.kernel.org
Suggested-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:53 +08:00
Chaithanya Lagisetty
f7a1064cce LoongArch: KVM: Free init resources if kvm_init() fails
kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the
per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the
perf callbacks, and then calls kvm_init(). If kvm_init() fails its
result is returned directly, but since module_init() does not run the
module_exit() stuff on failure, so kvm_loongarch_env_exit() is never
called and those resources are leaked.

So call kvm_loongarch_env_exit() when kvm_init() fails, matching the
teardown-on-failure pattern used by riscv_kvm_init().

Cc: stable@vger.kernel.org
Fixes: 2bd6ac6872 ("LoongArch: KVM: Implement kvm module related interface")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:53 +08:00
Tiezhu Yang
30419a0aa1 LoongArch: BPF: Fix off-by-one error for insn_is_cast_user()
In the LoongArch BPF JIT code, the branch offset represents the number
of instructions. An offset of 1 means the target of the "beq" is the
current PC plus 1 instruction (PC + 4 bytes). This matches the exact
same path as the sequential non-branch execution, the "or" instruction
is always executed for the cast_user JIT arm in build_insn().

If the pointer is not NULL, there is no side effect. But if the pointer
is NULL, it is incorrectly combined with the base address and turns into
a non-zero address, meaning a zero arena offset no longer casts to NULL.

Fix this by changing the branch offset from 1 to 2, which properly skips
the "or" instruction and jumps directly to the "move_reg" instruction if
the pointer is NULL, ensuring the destination register is safely cleared
to 0.

Cc: stable@vger.kernel.org
Fixes: 4fdb5dd8ae ("LoongArch: BPF: Implement bpf_addr_space_cast instruction")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Jérémy Jean
72ce4b2467 LoongArch: Avoid preempt count underflow without probe
LoongArch uses break 11 for the breakpoint placed after an instruction
that Kprobes executes out of line. Since userspace can issue the same
break instruction, do_bp() can reach kprobe_singlestep_handler() when
there is no current probe.

The handler actually returns false in this case, but it first calls
preempt_enable_no_resched(). The corresponding preempt_disable() is done
by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run
here. As a result, an ordinary userspace breakpoint (code 11) underflows
the current task's preempt count.

This also makes in_interrupt() return true until the task schedules. One
visible consequence is the socket cgroup attribution: cgroup_sk_alloc()
treats the allocation as interrupt context and assigns the socket to the
root cgroup. A socket opened from the SIGTRAP handler can then avoid a
BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup.

Return as soon as kprobe_running() reports no active probe.

The same check has appeared in [PATCH v10 2/4] of the original LoongArch
Kprobes series, but was dropped before the feature reached mainline.

Cc: stable@vger.kernel.org
Fixes: 6d4cc40fb5 ("LoongArch: Add kprobes support")
Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Wentao Guan
c3f2feace5 LoongArch: Do not save/restore percpu base register in rethook trampoline
The rethook trampoline saves $r21 ($u0), the percpu base, into its frame
at entry and restores it at exit. Inbetween rethook_trampoline_handler()
may schedule via preempt_enable_notrace().

If the task migrates to another CPU, the frame's $r21 holds the old
CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until
the next user->kernel transition heals $r21, all this_cpu_*() accesses
(runqueues, RCU per-CPU data, timer tick programming, FPU ownership)
hit the wrong CPU's percpu area.

Under kretprobe-heavy preemptible load this can corrupt scheduler and
timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings,
WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs
parking in the idle loop with the constant timer never re-armed (hard
lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths
plus heavy file churn (OS install / unsquashfs).

By convention $r21 always holds the current CPU's percpu base in kernel
mode: SAVE_SOME() at exception entry reloads it only when coming from
user mode, and RESTORE_SOME() restores it only when returning to user
mode; the context-switch path never writes it. Therefore the live $r21
at trampoline exit is already correct, and nothing inbetween can change
it legitimately (kernel C code cannot write a global register variable).
The same flaw existed even in the pre-rethook kretprobe trampoline since
v6.3; it was carried over when rethook replaced it. Drop both the save
and the restore here. Drop the restore is enough to solve the issue, and
drop the save is to keep the code tidy and no need to clear it.

Cc: stable@vger.kernel.org # v6.3+
Fixes: 3f55368600 ("LoongArch: Add kretprobes support")
Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Anthony Iliopoulos
3e1b64bd8c LoongArch: Remove unused setup_profiling_timer() function
setup_profiling_timer() is not used by any code at this point. Since a
default weak implementation exists, there is no need to still keep this
arch-specific definition around. Remove it along with the now-redundant
profile header includes.

Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:43 +08:00
Hemanth Selam
20a9e97137 LoongArch: Fix typo "avaliable" in comment of vmlinux.lds.S
Correct "avaliable" to "available", reported by scripts/checkpatch.pl
using the misspelling list in scripts/spelling.txt. It only touches the
comments, no code changes.

Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:24 +08:00
Nathan Chancellor
63b6a48c95 LoongArch: Do not select HAVE_RUST when KASAN is enabled
After commit 2625480a1b ("hardening: Default randstruct off with rust
for better allmodconfig support"), which allows Rust to be enabled for
allmodconfig, ARCH=loongarch allmodconfig starts failing with:

  error: kernel-address sanitizer is not supported for this target

  error: aborting due to 1 previous error

  make[4]: *** [rust/Makefile:741: rust/core.o] Error 1

For the same reason as the commit 84a0f7caaf ("ARM: Do not select
HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN
is enabled until the loongarch64-unknown-none-softfloat target in rustc
supports KASAN.

Cc: stable@vger.kernel.org
Fixes: 90868ff9ca ("LoongArch: Enable initial Rust support")
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-09-04 21:44:23 +08:00
Eduard Zingerman
6b31560c6b
selftests/bpf: No non-NULL inference from an imprecise zero register
Check that a register-form NULL check does not lift PTR_MAYBE_NULL on
a path where the compared register is non-zero. W/o the previous patch
the program is accepted.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-8-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:05 +02:00
Eduard Zingerman
6aed0134d3
bpf: Mark the zero register precise for a register-form NULL check
check_cond_jmp_op() accepts "if rA <op> rB" as a NULL check for a
nullable pointer rA when rB is a scalar known to be zero,
lifts PTR_MAYBE_NULL from rA in the corresponding branch and does not
mark rB precise. Consider the following program:

  r0 = bpf_get_prandom_u32();
  r6 = 1;                  /* the r6 == 0 path is explored first */
  if (r0 == 0) goto 1f;
  r6 = 0;
1:
  r0 = bpf_map_lookup_elem(map, &0);  /* absent, NULL at runtime */
  if (r0 == r6) goto 2f;   /* taken as a NULL check for r0       */
  *(u8 *)(r0 + 0);         /* verifier: map value; runtime: zero */
2:
  return 0;

The r6 == 0 path is explored first and the dereference is accepted.
The r6 == 1 path is pruned at the checkpoint recorded for (1),
so the comparison is never verified with a non-zero r6. At runtime a
failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the
program dereferences a pointer that is zero.

Fixes: 2f4cb53eed ("bpf: detect non null pointer with register operand in JEQ/JNE.")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
836b2fe544
selftests/bpf: Check that JMP32 pointer vs zero jumps are not predicted
Add jmp32_ptr_vs_zero_jne: the fall-through of the 32-bit compare, which
the verifier used to skip, contains an out of bounds map value access,
hence w/o the previous patch the program is accepted. See previous patch
for detailed description.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-6-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
e51179a4e0
bpf: Don't predict JMP32 pointer vs zero comparisons
Consider the following program:

        r1 = map_value;      /* low 32 bits are zero at runtime */
        r6 = 0xdead000000000000;
        if w1 != 0 goto l1;
    l0: r1 += r6;
        r2 = *(u64 *)(r1 + 0);
        exit;
    l1: r6 = 0;
        goto l0;

At the moment is_branch_taken() reports the jump as always taken,
because it does not distinguish between BPF_JMP and BPF_JMP32
comparisons when processing 'if w1 != 0 ...'.

Fixes: cac616db39 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-5-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:04 +02:00
Eduard Zingerman
bc412b3fb1
selftests/bpf: Check the linked regs cap for the compared register
linked_regs_too_many_regs checks that collect_linked_regs() ties at most
LINKED_REGS_MAX registers for a single jump. Compare r5 instead of r0,
so that the register the jump compares is itself the member that does
not fit, and check that it comes out of the jump unlinked.

W/o the previous patch env->{false,true}_reg{1,2} bring r5's id back and
insn 7 is logged as "R5=scalar(id=1,...)".

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-4-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:03 +02:00
Eduard Zingerman
73a98f9681
bpf: Don't resurrect a scalar id dropped by collect_linked_regs()
check_cond_jmp_op() copies the compared registers into
env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies
those snapshots back into both branch states afterwards.

collect_linked_regs() records at most LINKED_REGS_MAX members of a
linked registers group in the jump history and calls clear_scalar_id()
for every member that does not fit. The compared register is not exempt
from that.

As a consequence, sync_linked_regs() might adjust ranges for more
registers than bpf_bt_sync_linked_regs() can propagate precision to.

Collect the linked registers before the snapshots are taken instead.
This might lead to some unnecessary clear_scalar_id's, but from
previous testing situations with many linked registers are
extremely rare.

Fixes: ec1d77cb0e ("bpf: Use bpf_verifier_env buffers for reg_set_min_max")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-3-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:03 +02:00
Eduard Zingerman
6752b90ccf
selftests/bpf: No non-NULL inference from unbounded offset pointers
Check that a comparison against a pointer whose offset is not bounded
from above does not make the verifier infer that a nullable pointer is
not NULL, and that a bounded offset still does. W/o the previous patch
the first test is accepted.

Reported-by: Nicholas Carlini <npc@anthropic.com>
Suggested-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-2-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:02 +02:00
Eduard Zingerman
67b529f521
bpf: Don't infer non-NULL from a pointer with an unbounded offset
reg_not_null() decides that a register holds a non-NULL value by
looking at its type alone. For pointer types that allow arithmetic the
type only guarantees a non-NULL base, in case of an unbound offset
the runtime offset value might still add up to NULL.
Consider the followng program:

  r6 = bpf_map_lookup_elem(map, &0);  /* present */
  if (r6 == 0) return 0;
  r7 = bpf_map_lookup_elem(map, &1);  /* absent, NULL at runtime */
  r8 = r7;
  r8 -= r6;     /* pointer - pointer: unknown scalar, -r6 */
  r8 <<= 1;
  r8 >>= 1;     /* any non-negative offset is accepted by */
                /* check_reg_sane_offset_ptr() */
  r6 += r8;     /* verifier: map value;    runtime: zero  */
  if (r7 != r6) return 0;
  *(u8 *)(r7 + 0);  /* r7 is inferred non-NULL, both are zero */

At runtime both registers are zero, the comparison is true and the
load faults with NULL pointer dereference.

Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null().

Fixes: cac616db39 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ")
Reported-by: Nicholas Carlini <npc@anthropic.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20260904083325.2083493-1-eddyz87@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-04 12:58:02 +02:00
Dave Airlie
c96294afbc A small fix on the error handling of an OA uapi and the
addition of a drm_info message to report FLAT_CSS base misalignment.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmqZ1RgACgkQ+mJfZA7r
 E8qyAwf9FrxuliHzaaSz0vxrIlL4LzCYarKbLc9quiSAXEu0TM5QhIYlJJu8PSrp
 ChZGAutqwG+0x8o/+ztbt+5ij21+FVWOK/PnGEmctBevd+bPPRKAWYghVgSOkFww
 OuUwUotEDicqIM+Ml8qjDUXgWNRgkeoLknKZH2XTWpRZxPAxZYcC5P6k+DVAN4pC
 zcurjW9gbcTci2OP9No8EtxuY8+3YCz/Jtwd/Sx1nw0gqoD5l2yPziwdKMOjd3XU
 imml0dnBEWQYPUliVojj2onZKM9ujR4JHSpFCKAHs5c8UN5srlIEFzh14QgR+9Ux
 4ZDXzmbzc3Y3z4oM+dsJOiY3LDUJTA==
 =XZIm
 -----END PGP SIGNATURE-----

Merge tag 'drm-xe-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

A small fix on the error handling of an OA uapi and the
addition of a drm_info message to report FLAT_CSS base misalignment.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/apnVOtDv4WAIoj_X@intel.com
2026-09-04 20:36:14 +10:00
Dave Airlie
7f78fe856e amd-drm-fixes-7.3-2026-09-03:
amdgpu:
 - SR-IOV fix
 - GFX8 fix
 - MES queue reset fix
 - GPUVM fixes
 - DCN 6 warning fix
 - DCN 3.5/3.6 fix
 - DML fix
 - Backlight fix
 - Colorop fix
 - DC get_estimated_bw() fix
 - devcoredump fix
 - Userq fixes
 - APU PSP fix
 - Cursor fix
 
 amdkfd:
 - MES queue eviction fix
 - MQD debugfs fix
 
 UAPI:
 - Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQQgO5Idg2tXNTSZAr293/aFa7yZ2AUCapmnvwAKCRC93/aFa7yZ
 2DbfAQCapkI0p5iRMd/2fk2JcdhhaHfTtwdNEKyiHx7Z8Fyo7wD/egYUpCbhpy4W
 6bavqT8G5Gkn4+myqJmD9bIVoWmdlAA=
 =tJ2Q
 -----END PGP SIGNATURE-----

Merge tag 'amd-drm-fixes-7.3-2026-09-03' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes

amd-drm-fixes-7.3-2026-09-03:

amdgpu:
- SR-IOV fix
- GFX8 fix
- MES queue reset fix
- GPUVM fixes
- DCN 6 warning fix
- DCN 3.5/3.6 fix
- DML fix
- Backlight fix
- Colorop fix
- DC get_estimated_bw() fix
- devcoredump fix
- Userq fixes
- APU PSP fix
- Cursor fix

amdkfd:
- MES queue eviction fix
- MQD debugfs fix

UAPI:
- Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260903174712.584320-1-alexander.deucher@amd.com
2026-09-04 20:34:31 +10:00
Jiri Slaby (SUSE)
797b13a7de irqdomain: Delete irq_domain_add_linear()
7.3-rc1 is free of calls to irq_domain_add_linear(), so it can be finally
deleted.

According to Dongliang Mu, the related paragraph in the Chinese docs is now
obsolete. So drop it completely.

Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Link: https://patch.msgid.link/20260901070450.255507-1-jirislaby@kernel.org
2026-09-04 08:40:07 +02:00
Yao Kai
a3b8d46fe4 futex: Prevent rcuwait use-after-free during requeue PI
On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report
(slab-out-of-bounds) in futex_requeue_pi_complete() invocation of
rcuwait_wake_up().

The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's
stack. An early wakeup can race with a PI requeue as follows:

        waiter                          requeue task
        ------                          ------------
futex_wait_requeue_pi()
  futex_do_wait()
    schedule()
                                       futex_requeue
                                         futex_proxy_trylock_atomic()
                                           futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS
* timeout/ signal wakes waiter *
  futex_requeue_pi_wakeup_sync()
   Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT
                                           requeue_pi_wake_futex
                                             futex_requeue_pi_complete()
                                               cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED
    rcuwait_wait_event()
      if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT)
       break /* no schedule() */

 /* q.pi_state->owner == current */
 futex_private_hash_put()
 /* return from syscall */
                                              rcuwait_wake_up(&q->requeue_wait)
                                                /* q is gone */

futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before
calling rcuwait_wake_up(). The waiter observes this state in
rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event().
Here, the waiter is free leave the syscall before requeue task can
complete the wake.

To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED
case.
This state is only published by requeue_pi_wake_futex(), which saves
q->task before futex_requeue_pi_complete() and wakes the waiter via
wake_up_state().

This wake is intended to wake the waiter from its futex_do_wait() sleep.
If the waiter is still sleeping there, it can not get into the
Q_REQUEUE_PI_WAIT state (and require this removed wake).
Should the waiter be woken up from futex_do_wait() by other means (as in
this example) and sleep in futex_requeue_pi_wakeup_sync() then the
wake_up_state() from requeue_pi_wake_futex() will wake it, too.
Should the waiter task terminate before wake_up_state() had a chance to
wake the task then the task pointer does not become invalid because the
futex_hash_bucket::lock is held and the task pointer is RCU protected.

[bigeasy: Updated comment and commit message]

Fixes: 07d91ef510 ("futex: Prevent requeue_pi() lock nesting issue on RT")
Signed-off-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de
2026-09-04 08:14:15 +02:00
Sebastian Andrzej Siewior
912edebe85 futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling
There is rt_mutex_{pre|post}_schedule() around
rt_mutex_wait_proxy_lock() to ensure that sched_submit_work()/
sched_update_worker() is invoked before we schedule out and block on
rt_mutex while waiting for it become available.

The reason is that blocking on rt_mutex assigns a pi_waiter for the PI
chain and sched_submit_work() will also assign a pi_waiter if it blocks
on lock but a this point we already have a waiter assigned.
We can't skip sched_submit_work() entirely because I/O relies on the
fact that I/O queue is flushed while it blocks on a sleeping lock.
Therefore sched_submit_work() is moved before we block on the lock.

Sleeping lock in this context means mutex or rw_semaphore not spinlock_t
on PREEMPT_RT. Because the mutex abstraction on PREEMPT_RT uses the same
abstraction as the futex proxy lock, the futex code ended up using
rt_mutex_{pre|post}_schedule(), too.
Using it is/ was just to keep the task_struct::sched_rt_mutex assertion
happy. Futex proxy lock is used only in the syscall context of a task.
At this point it never got any I/O that needs to be flushed and it can't
be a workqueue that needs to notify that it will be scheduled out.
Therefore sched_submit_work() does nothing here.

By mistake futex_wait_requeue_pi() -> rt_mutex_wait_proxy_lock() did not
get the rt_mutex_{pre|post}_schedule() annotation. This was not noticed
because in this callchain the lock is (usually) not contended and so
rt_mutex_slowlock_block() does not schedule, triggering the assert.

Adding rt_mutex_pre_schedule() here looks wrong (as noted by PeterZ)
because at this point there is a pi_waiter recorded and invoking
sched_submit_work() with a possible lock contention would be wrong.

Add rt_mutex_futex_{pre|post}_schedule() which toggles the
sched_rt_mutex assert and does not involve sched_submit_work(). Add
asserts here to ensure that sched_submit_work() would do nothing. Use it
only in futex proxy lock case which is rt_mutex_wait_proxy_lock().
Remove it from futex_lock_pi().

Fixes: d14f9e930b ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
Reported-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260901135453.3121948-2-bigeasy@linutronix.de
Closes: https://lore.kernel.org/all/20260717084922.4153317-2-yaokai34@huawei.com
2026-09-04 08:14:15 +02:00