Commit 6f86bdeab6 ("tracing: Fix bad hist from corrupting named_triggers
list") described how a trigger that is registered but not on file->triggers
ends up freed while still on the global named_triggers list, and moved the
registration down so that hist_trigger_enable() follows it immediately. One
path still gets there. hist_trigger_enable() adds the trigger and takes it
straight back out when the event cannot be enabled:
list_add_tail_rcu(&data->list, &file->triggers);
update_cond_flag(file);
if (trace_event_trigger_enable_disable(file, 1) < 0) {
list_del_rcu(&data->list);
update_cond_flag(file);
ret--;
}
so the list walk in hist_unregister_trigger() matches nothing, test stays
NULL, and the ->free() that would call del_named_trigger() is skipped.
out_unreg falls through to out_free, which frees the trigger anyway:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff8880091d3160 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 69:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Leave the trigger where hist_unregister_trigger() can find it and let that
undo the registration, which is the only code that knows all of what
cmd_ops->init() took: the named list entry, the hist_pad reference, the
reference on the trigger a named histogram is shared with, and the copied
cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(),
whose sm_ref and buffered event reference are otherwise left behind.
Since ->free() releases trigger_data and, for a trigger that does not share
its histogram, hist_data with it, out_unreg can no longer fall through to
out_free. For a trigger that does share, hist_register_trigger() has
already destroyed the caller's hist_data, so the fall-through was reading
freed memory there as well.
Move the enable_timestamps check in hist_unregister_trigger() above the
->free() call for the same reason: hist_data does not outlive it once the
trigger being removed is the one that owns it.
Cc: stable@vger.kernel.org
Fixes: 067fe038e7 ("tracing: Add variable reference handling to hist triggers")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
event_hist_trigger_named_init() puts the trigger on the global
named_triggers list and only then takes the reference on the trigger it
shares its histogram with:
data->ref++;
save_named_trigger(data->named_data->name, data);
ret = event_hist_trigger_init(data->named_data);
if (ret < 0) {
kfree(data->cmd_ops);
data->cmd_ops = &trigger_hist_cmd;
}
return ret;
event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and
nothing takes the trigger back off the list on the way out.
event_hist_trigger_parse() frees it, and the next lookup by name reads the
freed object:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff888009346860 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 67:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Do the reference first and publish once it has succeeded, so that nothing
which can fail runs after the trigger becomes findable.
Cc: stable@vger.kernel.org
Fixes: 7ab0fc61ce ("tracing: Move histogram trigger variables from stack to per CPU structure")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Tom Zanussi <zanussi@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock:
if (data->cmd_ops->init) {
ret = data->cmd_ops->init(data);
if (ret < 0)
goto out;
}
if (hist_data->enable_timestamps) {
ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
if (ret) {
hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
goto out;
}
The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable. event_hist_trigger_parse() then frees it
without taking it off the list, and the next lookup by name reads the
freed object:
~# cd /sys/kernel/tracing/events/sched/sched_switch
~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger
bash: echo: write error: Invalid argument
~# echo 'hist:name=foo:keys=common_pid' > trigger
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff88800915d760 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0x900
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 63:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Set the clock before the trigger is registered, so that nothing which
can fail runs after it is published, the way commit 6f86bdeab6
("tracing: Fix bad hist from corrupting named_triggers list") moved the
registration below the rest of the setup.
tracing_set_filter_buffering() is reference counted, so the init failure
path has to drop the reference that the clock block now takes first.
Cc: stable@vger.kernel.org
Fixes: a4072fe85b ("tracing: Add a clock attribute for hist triggers")
Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Correct "preceeded" to "Preceded", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Link: https://patch.msgid.link/20260907065607.36615-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Correct "availabe" to "available", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Link: https://patch.msgid.link/20260907062608.13924-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The .percent and .graph modifiers exist only for histogram values, but a
value carrying either of them has been rejected since v6.3. The example
in Documentation/trace/histogram.rst,
# echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \
events/sched/sched_switch/trigger
returns -EINVAL.
parse_field() sets the two flags only when the field is neither a key nor
a variable, that is, only on a value:
} else if (strncmp(modifier, "percent", 7) == 0) {
if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY))
goto error;
*flags |= HIST_FIELD_FL_PERCENT;
__create_val_field() then rejects a value for carrying them, so no field
can reach hist_trigger_print_val(), where both are implemented.
commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") added the check after a value with .buckets oopsed in
hist_field_name(). That happens because .buckets and .log2 make
create_hist_field() build a nested field in operands[0] which
hist_field_name() then walks into. The percent and graph flags do not
create an operand and are not read by hist_field_name(); they are only
used when printing a value.
Stop rejecting the two flags on a value. The check for variables is left
alone, where they are unreachable anyway because parse_field() rejects a
variable carrying them first.
With the two flags removed, the trigger above installs and prints as
documented:
{ prev_comm: rcu_preempt } hitcount (%): 0.00
{ prev_comm: init } hitcount (%): 99.98
Totals:
Hits: 237896
Cc: stable@vger.kernel.org
Fixes: e0213434fe ("tracing: Do not let histogram values have some modifiers")
Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
print_entries() uses n_entries both as the number of sort entries and as
its own return value, so the -ENOMEM it stores when the stats allocation
fails overwrites the count that the cleanup still needs:
n_entries = tracing_map_sort_entries(map, ...);
if (n_entries < 0)
return n_entries;
...
if (!stats) {
n_entries = -ENOMEM;
goto out;
}
...
out:
tracing_map_destroy_sort_entries(sort_entries, n_entries);
tracing_map_destroy_sort_entries() takes an unsigned int and loops up to
it, so -ENOMEM arrives as 4294967284. It walks an array of at most
map->max_elts pointers and calls destroy_sort_entry(), which dereferences
and frees, on whatever lies past the end.
Reading the hist file of a trigger with a .percent value, with that
allocation forced to fail:
BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0
Read of size 8 at addr ffffc90000045000 by task init/1
tracing_map_destroy_sort_entries+0xa0/0xb0
hist_show+0x6f7/0x1df0
seq_read_iter+0x2b8/0x1190
vfs_read+0x176/0xa40
The buggy address belongs to a 4-page vmalloc region starting at
ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50
A few pages further the fault is fatal. The registers at the oops confirm
the bound: the loop's end pointer less the array start, over the pointer
size, is 4294967284.
Return the error in a separate variable and leave n_entries holding the
count, the way tracing_map_sort_entries() does on its own error path.
The stats block is only entered for a value carrying .percent or .graph,
which __create_val_field() has rejected since v6.3, so this cannot be
reached in mainline as it stands. It becomes reachable again with
"tracing: hist: let values keep the percent and graph modifiers", so it
should be applied first.
Cc: stable@vger.kernel.org
Fixes: abaa5258ce ("tracing: Add .percent suffix option to histogram values")
Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Writing a hist trigger whose value or variable carries a modifier that is
not allowed there leaks the fields that were built for it.
__create_val_field() takes the field from parse_expr() and stores it in
hist_data->fields[] only after the modifier checks have run:
hist_field = parse_expr(hist_data, file, field_str, flags, var_name,
&n_subexprs);
...
if (hist_field->flags & HIST_FIELD_FL_VAR) {
if (hist_field->flags & (...))
goto err;
} else {
if (hist_field->flags & (...))
goto err;
}
hist_data->fields[val_idx] = hist_field;
Both checks jump past that store, and the err label returns without
freeing anything. The error unwinds to create_hist_data(), which calls
destroy_hist_data() -> destroy_hist_fields(), and that reaches a field
only by walking fields[]. A field that never got there is unreachable.
commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") set ret to -EINVAL and fell through to the store, which left
the field owned by fields[] and freed along with the rest of hist_data.
Splitting the check into a value case and a variable case replaced that
fall-through with a goto that skips it.
With CONFIG_DEBUG_KMEMLEAK, 200 writes of
# echo 'hist:keys=prev_pid:vals=next_pid.log2' > \
events/sched/sched_switch/trigger
each correctly rejected with -EINVAL, leave 332 unreferenced objects
(63744 bytes) reported at create_hist_field(); 200 install and remove
cycles of a valid trigger leave none. A '.log2' field is two
allocations, since create_hist_field() puts the plain field in
operands[0] of the log2 field, and both are reported.
Use destroy_hist_field() rather than __destroy_hist_field() so that
operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF,
which is what an operand owned by hist_data->var_refs[] needs; the
rejected field itself is never a var ref, because a var ref never carries
a modifier flag.
Cc: stable@vger.kernel.org
Fixes: e30fbc618e ("tracing/histograms: Allow variables to have some modifiers")
Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
create_var_ref() allocates a VAR_REF hist_field and then calls
init_var_ref() to fill it in. When that fails the field is leaked.
commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made destroy_hist_field() return early for
HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's
var_refs[] array instead. create_var_ref() adds the field to that array
only after init_var_ref() has succeeded, so on this path the field is in
neither place and nothing frees it. The call was correct when it was
written, before var refs were taken out of destroy_hist_field().
init_var_ref() cannot free it either. The caller owns the field, so
init_var_ref() undoes only its own string allocations and leaves the
field alone. Freeing it there would leave create_var_ref() passing freed
memory to destroy_hist_field(), which reads its flags.
Call __destroy_hist_field(), which frees the field without consulting
the flag.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com
Fixes: 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy var_refs")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Using the same variable three or more times in one hist trigger leaks the
variable reference and its strings when the trigger is removed.
commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made a trigger's var_refs[] array the only owner of a var ref:
destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field
expressions never destroy one. One entry, freed once, no count needed.
commit 8bcebc77e8 ("tracing: Fix histogram code when expression has same
var as value") then made repeated references share one object and added a
count of them. Only the increment side exists, since those expressions
still return early and never drop a reference, so __destroy_hist_field()
sees how many references were created rather than how many are left. It
frees when the decremented count is 0 or 1, so two references work and
three or more leak.
Sharing kept one array entry per object, and create_var_ref() searches and
appends within a single trigger, so nothing outside it holds the object.
Removing a trigger whose variables are still referenced is already refused
by check_var_refs() with -EBUSY. Drop the count and free unconditionally.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com
Fixes: 8bcebc77e8 ("tracing: Fix histogram code when expression has same var as value")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When a graph entry does not fit in the trace_seq, print_graph_entry()
saves it in the iterator's fgraph_data and reprints it on the next read.
The entry has already been consumed from the ring buffer by then, so the
copy is all that is left of it.
The copy is sized with iter->ent_size, which no longer describes the
saved entry but whatever entry the iterator has moved on to. The
argument count is derived from the same field, so a 72 byte entry saved
and then reprinted ahead of a 48 byte return entry loses its arguments.
Record the size next to the failure flag, so that the two are always set
together, and restore it before reprinting.
Cc: stable@vger.kernel.org
Fixes: ff5c9c576e ("ftrace: Add support for function argument to graph tracer")
Link: https://patch.msgid.link/20260906034406.1335316-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
FGRAPH_MAX_INDEX has no user, and it expands to FGRAPH_INDEX_SIZE and
FGRAPH_RET_INDEX, neither of which is defined anywhere in the tree. It
was added in that form by commit 91c46b0aa9 ("function_graph:
Implement fgraph_reserve_data() and fgraph_retrieve_data()"), which
introduced the current data word layout under new names, so anything
referencing it would have failed to build ever since.
Remove it.
Link: https://patch.msgid.link/20260905211922.1196366-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
destroy_user_event() destroys the event's fields before attempting to
remove the trace event call. If user_event_set_call_visible() fails,
e.g. because the event is still enabled and trace_remove_event_call()
returns -EBUSY, the event is left registered with an irreversibly
destroyed field list. Any subsequent interaction with the event then
operates on an empty field list while it is still fully visible in
tracefs.
Move the field destruction after the call removal, and splice the
field list back onto the event when the removal fails so the event
remains in a consistent state.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260904115223.2976446-1-bsdhenrymartin@gmail.com
Fixes: 7f5a08c79d ("user_events: Add minimal support for trace_event into ftrace")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Reviewed-by: Beau Belgrave <beaub@linux.microsoft.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
A collection of device-specific small fixes. At this time, the
majority of changes are about ASoC while we have usual suspects like
HD- and USB-audio quirks. Some highlights below.
ASoC Intel / SoundWire:
- Fix bus and stream resource leaks at error path in avs and hda-ext
- More fixes and refactoring in avs for constraining MSBs, async
handling d0ix
- Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682
machines
- Fix uninitialized stream configurations in Realtek SoundWire codecs
- Adjust latency control to fix no-sound issue on RT721-SDCA
ASoC AMD:
- Avoid binding for the acp-da7219-max98357a machine driver
- Add quirks for Acer Nitro AN17-41 and HP 255R G10
- Fix memory leaks in ACP6x
ASoC Codecs & Platforms:
- Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM
imbalances
- Split stereo streams across mono amps on tas2783-sdw
- Fix pop noise on es8326 and enable_count underflow on es8389
- Various fixes for fsl_micfil, sprd, sti, and publish OF module
aliases
- Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs
HD-audio:
- Fix for channel status notification changes
- Quirks for HP laptops
USB-audio:
- Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers
- More hardening in usx2y and us122l drivers
- Quirks for Behringer devices
Misc:
- Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm
- Fix S/PDIF passthrough on CA20K2 in ctxfi
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmqj+8AOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+7Uw//TSbvionNeY4KPciLwDvscEbwWUYLVIJOQ6zp
UMKKIANtZRMay98CK29fijqM5DnVOZy3n4D62s7ZD9jRxoIYbCVGtHA1akAjxjB6
q+xq/8V9EjGcJpCOR81Umlk54NlhclG/CTMpskyjqkgHe/hAxTaTs+AuqT99HPDe
MmcCkMdWq/3KSHi4zpOLoBys6/G+yOkd3/CiklZDRAKMMxvd2BNfWYpus3pVw4j9
D9Q1HryV7dwBRnodRuCf8EUWWjv63+v1arzyRH82s5HUlLkssr1LwTPqVOKtSbNt
nNwMw2Lv9wX8i6BhlJb8piFFomqJGYVpk1fpTDcAaq4Yc4j8xRidNHTZZvuhGYl0
R9wdYgFIAyYdMfW09TteOIHEFYPRDcXmD5i7efqc3w1h/epBNwJWlF0xGRZUDPi1
7pNIQqUmHgzpAKBtfS/Q+HyCJ/+3xgJXM3Fl9o0mdOAvwk6SYfQh9sm+lSrxyM7R
cdGbyJFog2QKxXxQtMuvGNNKKNVRbbZjB+NsASkky8bCzcUcTxSEWlg3lXHHT3Pl
HKunHzAXxBpMaa1PZPtucq5TZgR/CJ2PkVPpz+8L0myK86KXBM2vqQgkvmDXzfXD
DqDa3yhVvKRLjpmixrexKwdppHMvyrdnmwtFVUqCZn4omMCD+wGYD31lPROQt4gF
kkf04XU=
=ihAY
-----END PGP SIGNATURE-----
Merge tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of device-specific small fixes. At this time, the
majority of changes are about ASoC while we have usual suspects like
HD- and USB-audio quirks. Some highlights below.
ASoC Intel / SoundWire:
- Fix bus and stream resource leaks at error path in avs and hda-ext
- More fixes and refactoring in avs for constraining MSBs, async
handling D0ix
- Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682
machines
- Fix uninitialized stream configurations in Realtek SoundWire codecs
- Adjust latency control to fix no-sound issue on RT721-SDCA
ASoC AMD:
- Avoid binding for the acp-da7219-max98357a machine driver
- Add quirks for Acer Nitro AN17-41 and HP 255R G10
- Fix memory leaks in ACP6x
ASoC Codecs & Platforms:
- Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM
imbalances
- Split stereo streams across mono amps on tas2783-sdw
- Fix pop noise on es8326 and enable_count underflow on es8389
- Various fixes for fsl_micfil, sprd, sti, and publish OF module
aliases
- Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs
HD-audio:
- Fix for channel status notification changes
- Quirks for HP laptops
USB-audio:
- Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers
- More hardening in usx2y and us122l drivers
- Quirks for Behringer devices
Misc:
- Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm
- Fix S/PDIF passthrough on CA20K2 in ctxfi"
* tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (65 commits)
ALSA: hdspm: Add a new PCI device ID (1d18:3fc6) for RME HDSPe AIO PCI express audio
ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards
ALSA: hda: Report a change when only the channel status bytes move
ALSA: us122l: Prevent write upgrades for read mappings
ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Max G2 speaker
ASoC: cs35l56: Fix race between kexec and snd_soc_register_component()
ASoC: amd: yc: add quirk for Acer Nitro AN17-41 internal mic
ASoC: mt6351: Publish the OF module alias
ASoC: Intel: SST: Publish the PCI module aliases
ASoC: bcm: bcm63xx: Publish the OF module aliases
ALSA: usb-audio: Add quirk flags for Behringer UV1
ALSA: usb-audio: Add boot quirk for Behringer CM1A
ALSA: hda/realtek: Add quirk for HP Omen 16-wd0xxx mute LED
ALSA: usbusx2y: validate URB actual_length in interrupt callback
ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf
ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough
ALSA: usb: 6fire: Avoid embedded URBs
ALSA: usb: hiface: Avoid embedded URBs
ALSA: usb: ua101: Avoid embedded URBs
ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev
...
PPR and GAlog interrupt is enabled only if buffer is allocated.
(See amd_iommu_enable_ppr_log() and iommu_ga_log_enable()).
The duplicate check in interrupt hanlder path is unnecessary
and can be removed.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The amd_iommu_irq_remap flag is already validated during irq remapping
domain creation (before calling amd_iommu_create_irq_domain()). The
duplicate check in irq_remapping_select() is unnecessary and can be
removed.
Additionally, mark amd_iommu_irq_remap as static.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd
with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer
arithmetic:
data = ((void *)hdr) - size;
to wrap around on 32-bit systems (or when pointer subtraction overflows).
Because data wraps around, the subsequent bounds check:
if ((unsigned long)data < initrd_start)
evaluates to false, bypassing the check. The kernel then calls
xbc_calc_checksum(data, size), which attempts to read 4GB of memory,
hitting unmapped pages and triggering a fatal kernel page fault during
early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an
unbounded 32-bit size can similarly bypass the initrd_start check.
Fix this by:
1. Ensuring the initrd is at least large enough to contain the bootconfig
footer and verifying hdr is within the initrd bounds.
2. Checking that size does not exceed XBC_DATA_MAX and does not exceed
the available space between initrd_start and hdr before performing
pointer subtraction.
Link: https://lore.kernel.org/all/178905333479.213925.1358412668943562406.stgit@devnote2/
Fixes: de462e5f10 ("bootconfig: Fix to remove bootconfig data from initrd while boot")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/
Assisted-by: Antigravity:gemini-3.8-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Sashiko reported that on 32-bit systems, if an attacker crafts size in
the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around
(for instance, if size is 0xFFFFFFFF), the size check in
load_xbc_from_initrd() can be bypassed:
if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) {
pr_err("bootconfig size is too big\n");
return -E2BIG;
}
Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a
corrupted 32-bit size (e.g. 0xFFFFFFFF) against
stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if
size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size
directly into the 32-bit int size parameter of load_xbc_fd(), truncating
large standalone files (>= 2GB).
In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1,
resulting in malloc(0), an integer overflow in read(), and an
out-of-bounds null-byte write.
Fix this by:
1. Rejecting size > XBC_DATA_MAX or
size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd().
2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing
it to load_xbc_fd().
3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd().
Link: https://lore.kernel.org/all/178905332413.213925.3179977110281463499.stgit@devnote2/
Fixes: 950313ebf7 ("tools: bootconfig: Add bootconfig command")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260909161113.16C691F00A3A@smtp.kernel.org/
Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/
Assisted-by: Antigravity:gemini-3.8-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Rearming a queued timer with nonzero slack can leave the timerqueue out
of order. remove_and_enqueue_same_base() checks the new soft expiry
against its neighbours' hard expiries, then stores the new hard expiry
in the node without requeueing it.
For example, with A at 10 and B at 20, rearming A at 11 with slack 30
passes the neighbour check but leaves A's hard expiry of 41 before B's
20. The same function also caches the soft expiry in base->expires_next
when updating or inserting the first timer, giving next-event selection
an earlier deadline than the queue head's hard expiry.
Set the timer expiry before handling the queue. Use its stored hard
expiry for the in-place ordering check and both updates to
base->expires_next.
The early update is safe because remove_and_enqueue_same_base() runs
with base->cpu_base->lock held. The lock keeps the queue stable while
hrtimer_can_update_in_place() checks the new expiry against both
neighbours. If the check fails, timerqueue_linked_del() removes the node
without comparing expiry values before it is reinserted.
Fixes: eddffab828 ("hrtimer: Keep track of first expiring timer per clock base")
Fixes: 343f2f4dc5 ("hrtimer: Try to modify timers in place")
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260910143442.2018-1-parri.andrea@gmail.com
drm/i915 fixes for v7.3-rc3:
- Fix a memleak on perf config query error path
- Fix UHBR SST SDP splitting when sink doesn't support it
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/27458ccc4d6be77a0d440f32279586711f3294f0@intel.com
LOLLM pointed out a race condition in xrep_findparent_scan -- the
directory live update hook holds the directory ILOCK when it calls the
xchk_iscan_want_live_update predicate to figure out if it needs to
remember the live update, but xrep_findparent_scan drops the directory
ILOCK before advancing the cursor. Therefore, it's possible for a live
update to check the scan cursor after the scan drops the ILOCK but
before the scan updates its cursor. If this happens, we'll fail to
record the live update. Fix this by moving the cursor update logic
inside xrep_findparent_walk_directory.
Note that for non-directories it's ok to advance the cursor without
holding any ILOCK because the findparent scan only cares about directory
parents, not the children.
Cc: stable@vger.kernel.org # v6.10
Fixes: a07b455762 ("xfs: scan the filesystem to repair a directory dotdot entry")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed that xfs_parent_removename only partially initializes the
passed-in parent pointer arguments object. In the directory tree repair
code, we could decide to remove multiple links to a file, so we don't
want state from one call to bleed into the next one. Zero the whole
thing explicitly.
Cc: stable@vger.kernel.org # v6.10
Fixes: 3f31406aef ("xfs: fix corruptions in the directory tree")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xrep_dir_replay_removename is the function that replays a directory
entry removal from sc->ip into the temporary directory so that when we
swap the contents of sc->tempip and sc->ip, the directory is correct.
LOLLM noticed that we were passing the wrong inode pointer into
xrep_dir_init_args. It doesn't make sense to set rd->args.dp to
rd->args.dp so let's fix this.
Cc: stable@vger.kernel.org # v6.10
Fixes: 8559b21a64 ("xfs: implement live updates for directory repairs")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xchk_should_terminate can turn its @error argument into -EINTR if the
user is sitting on ^C. Unfortunately, this code here turns that into a
0 return, which isn't quite correct. LOLLM complains about this, though
I think it's a very minor matter because the only way -EINTR happens is
if there's a fatal signal.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that xchk_bmap_xref_rmap_cow skips the cross-reference
if the data-section rmapbt cursor is not present. However, this is
broken for realtime file data fork scanning, because they will have an
rtrmapbt cursor and not an rmapbt cursor. Fix the behavior by removing
the cursor checks because xchk_bmap_get_rmap already accounts for that.
Cc: stable@vger.kernel.org # v6.14
Fixes: 037a44d827 ("xfs: cross-reference the realtime rmapbt")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that the superblock scrubber doesn't check the new
fields that were added for internal realtime volumes when we added zoned
device support.
Cc: stable@vger.kernel.org # v6.15
Fixes: 2167eaabe2 ("xfs: define the zoned on-disk format")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Whilst running QA on XFS for-next as of 7.3-rc2 with MKFS_OPTIONS="-n
size=8192", I observed the following (trimmed) dmesg splat:
XFS: Assertion failed: args->total >= dp->i_nblocks - nblks, file: fs/xfs/libxfs/xfs_da_btree.c, line: 2387
WARNING: fs/xfs/xfs_message.c:104 at assfail+0x46/0x4a [xfs], CPU#0: xfs_scrub/1426511
CPU: 0 UID: 0 PID: 1426511 Comm: xfs_scrub Tainted: G W 7.3.0-rc2-djwx #rc2 PREEMPT(lazy) 6e418570b606a39783b0e7e7b30dc407b965f9e8
Tainted: [W]=WARN
RIP: 0010:assfail+0x46/0x4a [xfs]
RSP: 0018:ffffc900010d7890 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffffd1
RDX: 0000000000000000 RSI: 0000000000000021 RDI: ffffffffa059fd38
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000000a R11: 000000007fffffff R12: ffffc900010d7940
R13: ffff888368d8f980 R14: ffffc900010d7a48 R15: ffffc900010d78d0
FS: 00007f445c5ce680(0000) GS:ffff8884a97ea000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f443803b9a8 CR3: 0000000107a4b000 CR4: 00000000003506f0
Call Trace:
<TASK>
xfs_da_grow_inode_int+0x2e0/0x300 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_grow_inode+0x6e/0x150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_sf_to_block+0x149/0x870 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap_prep+0xe2/0x110 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap+0xfb/0x2f0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_rebuild_tree+0x99/0x100 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_directory+0x83/0x1c0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_attempt+0x4f/0x1e0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_scrub_metadata+0x393/0x5b0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_ioc_scrubv_metadata+0x306/0x570 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_file_ioctl+0xa4f/0x1150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
__x64_sys_ioctl+0x76/0xc0
do_syscall_64+0x7a/0x3b0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
This is a consequence of commit 0fe77e5758, which added the
following assertion to xfs_da_grow_inode_int:
ASSERT(args->total >= dp->i_nblocks - nblks);
Tracing this back to xrep_dir_swap_prep, I noticed that the xfs_da_args
object that's passed to xfs_dir2_sf_to_block sets args->total to 1.
This is incorrect because mkfs set the directory block size to 8k and
the filesystem block size to 4k. In other words, args->total should be
2 here, not 1.
Dave Chinner tripped over the same problem with the same branch through
a different channel -- his test setup set the fs block size to 1k, in
which case the directory block size is still set to 4k. Here,
args->total should be 4.
Changing the assignment of args->total to sc->mp->m_dir_geo->fsbcount
makes the assertion go away, but that isn't a complete fix. In
xrep_tempexch_estimate, we also incorrectly assume that a shortform
conversion requires 1 fsblock when it should be m_dir_geo->fsbcount.
Without that, we can under-reserve space in the transaction and cause a
filesystem shutdown.
Note that the xfs_dabuf_nfsb helper will compute the correct value for
directories and xattr, so we use that instead of open-coding the logic.
Also fix xrep_xattr_swap_prep to assign args->total via xfs_dabuf_nfsb
to avoid one logic bomb if we ever support multi-fsblock attrs.
Cc: stable@vger.kernel.org # v6.10
Cc: floss@jetm.me
Reported-by: dgc@kernel.org
Fixes: 629fdaf5f5 ("xfs: use atomic extent swapping to fix user file fork data")
Tripped-by: 0fe77e5758 ("xfs: assert the reservation covers each da fork growth")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
- create blend mode property for more driver planes
- Kconfig cleanups across the board
- sched: null pointer dereference fix in kunit tests
- ethosu misc fixes about error handling and corner cases handling
- ivpu fixes about buffer and metadata validation
- rockchip: fixes around buffer overflow and kconfig
- tc358768: fix bus flags and error handling
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaqJd2wAKCRAnX84Zoj2+
dqFCAYDycQJGGWRAjUwfVS8pQApFdY1kWJ6UA6L4kl+luQbO9g2/T6ZnrCMKtfCD
GcRzt9kBgLggzOf1hApF+o1fqSldKEqVQm17sGChXfU4p4c2XgUrAjgB5SuL7pIi
InrtooUpiw==
=xFoP
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2026-09-10' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
A fair amount of fixes this week as well:
- create blend mode property for more driver planes
- Kconfig cleanups across the board
- sched: null pointer dereference fix in kunit tests
- ethosu misc fixes about error handling and corner cases handling
- ivpu fixes about buffer and metadata validation
- rockchip: fixes around buffer overflow and kconfig
- tc358768: fix bus flags and error handling
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/aqJd5TPXpwqwsM0F@houat
erofs_bread() locates the target folio with
index = (buf->off + offset) >> PAGE_SHIFT;
but computes the in-folio offset without taking buf->off into account:
return buf->base + (offset & ~PAGE_MASK);
If buf->off is not page-aligned, the returned pointer misses the in-page
component of buf->off, so callers end up fetching data from a wrong
offset.
buf->off is set to sbi->dif0.fsoff in erofs_init_metabuf(), and fsoff can
be specified via the "fsoffset=" mount option, which only requires
block-size alignment. Therefore, on an image with a sub-page block size
(e.g. 512 bytes), a non-page-aligned fsoff (e.g. 512) triggers the issue,
since 512 is a multiple of the block size but not of PAGE_SIZE.
It can be reproduced by mounting an image that is placed at a
non-page-aligned offset:
mkfs.erofs -b512 -zlz4hc sub.erofs src/
# prepend 512 bytes of padding to the image
mount -t erofs -o loop,fsoffset=512 padded.erofs /mnt
which fails with
erofs (device loop0): cannot find valid erofs superblock
because the on-disk superblock (at offset 1024 within the image, i.e.
1536 within the padded file) is read from a wrong in-folio offset. With
this fixed, the very same image mounts successfully and its file contents
match those read from the unpadded image.
Fix it by including buf->off in the in-folio offset calculation, so that
it is consistent with the folio index calculation.
Fixes: c36ec00d7f ("erofs: add 'fsoffset' mount option to specify filesystem offset")
Signed-off-by: Binglei Wang <l3b2w1@gmail.com>
Reviewed-by: Gao Xiang <xiang@kernel.org>
Signed-off-by: Gao Xiang <xiang@kernel.org>
Quiesce sets ubq->force_abort for batch I/O. Recovery never clears
it, so batch fetch keeps failing with -ENODEV and the device stays
QUIESCED.
Fixes: a4d8837553 ("ublk: add UBLK_U_IO_FETCH_IO_CMDS for batch I/O processing")
Signed-off-by: Yang Xiuwei <yangxiuwei@kylinos.cn>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260821103047.369522-2-yangxiuwei@kylinos.cn
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The local "root" pointer is a temporary variable used during the device
search. Therefore, refcount related to the search iterators should be cleaned
up after the search is complete.
Use the __free() cleanup macro to ensure the refcount is decremented when the
temporary pointer goes out of scope.
Additionally, increment the refcount when caching a root pointer. This ensures
the in-use refcount is separate from the temporary search refcounting.
Finally, drop the redundant "root = NULL" before the second search loop. The
pci_get_class() iterator always decrements the refcount of its "from"
argument, so the first loop can only fall through with "root" already NULL.
Fixes: 0a4b61d9c2 ("x86/amd_node: Fix AMD root device caching")
Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com
Reported-by: Sashiko <sashiko-bot@kernel.org>
Assisted-by: LLM
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com
Replace snprintf() with scnprintf() in the thermal core sysfs code
to avoid compiler warnings about potential truncation of the names
of the sysfs attributes (Andy Shevchenko)
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmqi+F0SHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1tfUH/R7iidR7VkOYXJTR8JpeGl80Rvqyi7A8
RubleUVJOWOofnSneLIQdcjV5p2n7dzFb/tDBT4/pcTgOtarMWVbo11pMLyCQQOv
RQsXLBmMlgAWDFKad0/Vz/qCGJL0KtQcuBVy4Zjd86RDl6BiVBMk0lEPXMzDDOSM
HII1PH9BjDCpAsXxVAXjI7lPSjN/zcfgdszgZlr+1akAbF6DZ8sYlYblq2Q3e8f0
q8f47ksbN/Zs9hheZy5/P23CAu/cMxIkefMvSwQ63bdUu08NJEJh4JuvjpX1chtE
8Q/OLAoQDMEd7uo1B7NbFC5UitgkawGW9uT31nczg/0VKmDU/rBQZQo=
=WLSp
-----END PGP SIGNATURE-----
Merge tag 'thermal-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"Replace snprintf() with scnprintf() in the thermal core sysfs code to
avoid compiler warnings about potential truncation of the names of the
sysfs attributes (Andy Shevchenko)"
* tag 'thermal-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: sysfs: switch to use scnprintf() to suppress truncation warning
- Zero-initialize the policy cpumask and initialize the policy rwsem
before exposing the policy sysfs interface (Runyu Xiao and Zhongqiu
Han)
- Fix potential multiplication overflow when calculating freq in OPP
core (Colin Ian King)
- Fix use after free in _update_opp_table_clk() (Peter Griffin)
- Use %pe to print symbolic error name in OPP (Sumeet Pawnikar)
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmqi9w0SHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1vIsIAInaslreQyDQzuI0o0eZk/q8WOgCevz1
7LUJ5Uq7rRgyvc0ua2h9jChmjUDPL0qRxWY9UbnflliJt0WoXK7d69MLq3ABnHN9
oduernWbs3qPzqx7f52rIBU3JrmGLdsZSTAtZokPjUqGcuy6y7Z7KML2yheURhL0
yBqTtW3JhoVtDHyuYfdWMRixdjSy6C/UaUmMIo9lR1/yea+PkR+ZNOw7UPzWaMeC
5bdJlV2wsmttNMkfYm70z5biSJVoTqubNnJcTOmLWf2/cYi6OF0wIOV+T4CB/J/C
0QzzJbCW/VCVBVgP32WSIOjkdgMk01oJOHFtKNBQpe+WA+rV4C1RHao=
=KlxA
-----END PGP SIGNATURE-----
Merge tag 'pm-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These harden the cpufreq core against races with sysfs during policy
creation, fix two issues in the OPP (Operating Performance Points)
library, and make OPP print symbolic error names:
- Zero-initialize the policy cpumask and initialize the policy rwsem
before exposing the policy sysfs interface (Runyu Xiao and Zhongqiu
Han)
- Fix potential multiplication overflow when calculating freq in OPP
core (Colin Ian King)
- Fix use after free in _update_opp_table_clk() (Peter Griffin)
- Use %pe to print symbolic error name in OPP (Sumeet Pawnikar)"
* tag 'pm-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
opp: fix use after free in _update_opp_table_clk()
cpufreq: zero-initialize policy cpumask before sysfs publication
cpufreq: initialize policy rwsem before sysfs publication
opp: Use %pe to print symbolic error name
OPP: of: Fix potential multiplication overflow when calculating freq
Including fixes from Netfilter, Bluetooth and WPAN.
Current release - new code bugs:
- Bluetooth: hci_sync: fix not setting CE length properly
- eth: enic: match mailbox replies to request numbers
Previous releases - regressions:
- tunnels: drop stale dst when building an ICMP error for PMTUD
- ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()
(bug in the rtnl_lock -> RCU conversion)
- eth: bnxt_en: fix crashes on Thor2 due to OOB coalescing buffer accesses
- eth: bnxt_en: prevent queue stop with deferred completions
Previous releases - always broken:
- eth: ice: don't dereference pointers from TP_printk()
- eth: fix OOB writes on ethtool flow rule dump in 3 drivers
- eth: mlx5: fix FEC configuration with RS_544_514_INTERLEAVED_QUAD
- dsa: tag_brcm: legacy FCS: request needed tailroom
Misc:
- net: cap tx_queue_len at S16_MAX to prevent oversized ring alloc
- ipv6: flowlabel: cap duplicate leases per socket
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmqi3pQACgkQMUZtbf5S
IrvUIg//X9nIxY2F5PzJ5jD9p5ccXrQMLe7kT5AW2tP5PDC8d5PIv4Q5XzFKQPU7
XElAUKvBxmofwU2lqILYGi8AeUpqHZtKPY7XzKeqd6i72KOD6mGzzYNijqttBXcM
vFVtIeKExXjAwvNc2as1SeXVEAAAkBtrCFuMNHMq0C56yK4md/XVkCDHaJkomNit
geke1U8gut3rZddWKxp4WDbL8Wmx9yM0uDMBznO/+cwITObA0Hme3IgRndglzz7n
n4Ih+EG4tRrD3kUf6oePzKQ47cd+qnSVlVTCZUwB5E/HKqWJFXxSN4Sv+mez0sAS
rrI5hl+luNKUYrZ8/jiNlvajgAL4+AYpCKPDJbXrOW+z+x4BC2VYZBAHLoUr5ZAq
Z5OYU9SgD1oGntqkI8mAEiRTEu+4gjhIEhjENHEzqdjUogaBIp7MWwCrNBAnFWvs
2McmNfZZMVhxKpyYnndUStsVQySVPASb0CXeqTIO6PJsAp/HBjoMYKYKPhhwk0Gp
lE8zHjEnPVofRfXfT+oZnbS8is2nC9FjBy9ksIGcC7vyTOdPsoIBoB8JY0x/INRM
SOJvyxrdnVkMjiBejkdOa5X9HbD1cA/NVyzT2WEaZBGPmIqfNBgUIOxnXD4CShuy
9zX8qtHsUmmYxPteF30Uhfe0kyLQ9OnjUz2Bl++EruxpIE3+i48=
=f9J9
-----END PGP SIGNATURE-----
Merge tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Nothing too exciting, usual stream of fixes. Including fixes from
Netfilter, Bluetooth and WPAN.
Current release - new code bugs:
- Bluetooth: hci_sync: fix not setting CE length properly
- eth: enic: match mailbox replies to request numbers
Previous releases - regressions:
- tunnels: drop stale dst when building an ICMP error for PMTUD
- ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()
(bug in the rtnl_lock -> RCU conversion)
- eth: bnxt_en:
- fix crashes on Thor2 due to OOB coalescing buffer accesses
- prevent queue stop with deferred completions
Previous releases - always broken:
- eth:
- ice: don't dereference pointers from TP_printk()
- fix OOB writes on ethtool flow rule dump in 3 drivers
- mlx5: fix FEC configuration with RS_544_514_INTERLEAVED_QUAD
- dsa: tag_brcm: legacy FCS: request needed tailroom
Misc:
- net: cap tx_queue_len at S16_MAX to prevent oversized ring alloc
- ipv6: flowlabel: cap duplicate leases per socket"
* tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (164 commits)
selftests: tc-testing: test action batch failure cleanup
net/sched: act_api: release all action references on NEWACTION failure
openvswitch: fix wrong flag value in get_ipv6_ext_hdrs()
ipmr: account multicast table and route memory
net: phy: dp83td510: handle the active-high LED polarity mode
net: macb: initialize PTP state before registering clock
net: hsr: enable promiscuous mode on interlink port with fwd offload
ipv6: fix fib6 walker UAF on seq stop
net: stmmac: fix TX descriptor availability check for TSO traffic
net/rds: fix tcp stream corruption with large pages
net: mana: restore the XDP program pointer when pre-allocation fails
net: phy: dp83867: handle the active-high LED polarity mode
octeontx2-af: fix PF/CGX debugfs PCI bus lookup
net: net_failover: Fix the deadlock in net_failover_slave_name_change()
net: phy: mediatek-ge: disable EEE on the MT7530 PHY
tcp: reject non zerocopy devmem tx
net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support
net: dsa: mt7530: populate lpi_interfaces to fix EEE support
net: hinic: fix mailbox segment buffer overflow
net: sun4i-emac: fix missing of_node_put() for phy_node
...
A batch of bug fixes for the smb client:
- File type corruption fixes in reparse point handling: setting S_IFMT
bits without clearing the existing type first corrupted the file mode
(e.g. S_IFREG | S_IFCHR == S_IFLNK). Fixed in the WSL, POSIX and
native symlink reparse parsers. Also fixes an uninitialized SID
structure in the POSIX readdir path when parsing fails.
- Ownership mapping fixes: forceuid/forcegid mount options were
ignored in several code paths (SID-to-id mapping, WSL extended
attributes, POSIX extensions getattr), allowing an untrusted server
to dictate local file ownership despite explicit mount overrides.
- Heap overflow and overflow fixes in DACL rewriting: replacing short
SIDs with long ones could overflow the DACL buffer, and the u16
accumulator for DACL size could wrap around with enough ACEs.
- Reference count leak fixes in oplock break and deferred close:
duplicate oplock breaks on a queued work item leaked a
cifsFileInfo reference, and deferred close had a similar leak when
requeueing a running work item. Both cause busy-inode oopses on
unmount.
- DFS superblock use-after-free fix: the iterator callback stored a
raw superblock pointer without pinning it, racing with automount
expiry.
- One-byte slab OOB read in the native symlink parser when handling
share-root relative paths.
- Hardening of legacy SMB1 input: reject userspace-crafted
cifs.idmap key descriptions that bypass kernel origin checks, and
validate DataOffset in CIFSSMBRead() to prevent heap info
disclosure from a malicious server.
- DFS cache fix: defer metadata updates until target copying
succeeds to prevent partial-state cache entries on allocation
failure.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTcqRusfSdYROJQwGkpVtNKoQNdYwUCaqLMxAAKCRApVtNKoQNd
YwSyAQDUDSxCnDMmJbRr4e22oF/YrGSN/snp8cqrZlZh2pb5/gD/c2G3xMJA85YP
yL/G8auRWkpwDl0/Parqptjhx1c9YwE=
=PjPM
-----END PGP SIGNATURE-----
Merge tag 'cifs-fixes-7.3-rc3' of https://git.manguebit.org/linux
Pull smb client fixes from Paulo Alcantara:
- File type corruption fixes in reparse point handling: setting S_IFMT
bits without clearing the existing type first corrupted the file mode
(e.g. S_IFREG | S_IFCHR == S_IFLNK). Fixed in the WSL, POSIX and
native symlink reparse parsers. Also fixes an uninitialized SID
structure in the POSIX readdir path when parsing fails.
- Ownership mapping fixes: forceuid/forcegid mount options were
ignored in several code paths (SID-to-id mapping, WSL extended
attributes, POSIX extensions getattr), allowing an untrusted server
to dictate local file ownership despite explicit mount overrides.
- Heap overflow and overflow fixes in DACL rewriting: replacing short
SIDs with long ones could overflow the DACL buffer, and the u16
accumulator for DACL size could wrap around with enough ACEs.
- Reference count leak fixes in oplock break and deferred close:
duplicate oplock breaks on a queued work item leaked a
cifsFileInfo reference, and deferred close had a similar leak when
requeueing a running work item. Both cause busy-inode oopses on
unmount.
- DFS superblock use-after-free fix: the iterator callback stored a
raw superblock pointer without pinning it, racing with automount
expiry.
- One-byte slab OOB read in the native symlink parser when handling
share-root relative paths.
- Hardening of legacy SMB1 input: reject userspace-crafted
cifs.idmap key descriptions that bypass kernel origin checks, and
validate DataOffset in CIFSSMBRead() to prevent heap info
disclosure from a malicious server.
- DFS cache fix: defer metadata updates until target copying
succeeds to prevent partial-state cache entries on allocation
failure.
* tag 'cifs-fixes-7.3-rc3' of https://git.manguebit.org/linux:
smb: client: fix one-byte OOB read in smb2_parse_native_symlink()
smb: client: fail DACL rewrite when the new DACL exceeds 64K
smb: client: fix heap overflow in DACL owner/group rewrite
smb: client: fix file type corruption in cifs_reparse_point_to_fattr()
smb: client: fix file type corruption in posix_reparse_to_fattr()
smb: client: fix file type corruption in wsl_to_fattr()
smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()
smb: client: fix WSL reparse point uid/gid override
smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid
smb: client: fix uid/gid override in getattr with posix extensions
smb: client: fix cifsFileInfo reference leak in deferred close
smb: client: avoid leaking refcount when cifs_sb_tlink() fails
smb: client: avoid leaking refcount in cifs_queue_oplock_break()
smb: client: fill cache fields after populating cache in copy_ref_data()
smb: client: pin DFS superblock in iterator callback
smb: client: reject userspace cifs.idmap descriptions
smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
smb: client: reject short READ responses in CIFSSMBRead()
FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the
usercopy after dropping info->lock. vfb_remove() frees the colormap
immediately after unregistering the framebuffer, even when an open file
still holds a reference to fb_info. A concurrent driver unbind can
therefore free the colormap while the ioctl copies it to userspace.
KASAN reports:
BUG: KASAN: slab-use-after-free in _copy_to_user
Read of size 512 by task poc/125
_copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24)
fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211)
do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114)
Allocated by task 1:
fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108)
vfb_probe (drivers/video/fbdev/vfb.c:459)
Freed by task 124:
fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151)
vfb_remove (drivers/video/fbdev/vfb.c:489)
unregister_framebuffer() drops the registration reference, and fbdev calls
fb_destroy after the last put_fb_info(). Move the registered framebuffer's
cleanup into an fb_destroy callback so its colormap and screen buffer stay
alive until all file references have been released.
Fixes: 5e266e2e0e ("vfb: fix memory leaks in removal path")
Reported-by: co+c25629c98ba36ebe@bugs.sh
Cc: stable@kernel.org
Closes: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/
Assisted-by: Codex:gpt-5
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Link: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/
Signed-off-by: Helge Deller <deller@gmx.de>
John reports that since commit:
a11f6ca9ae ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN")
users of Linux inside Solaris ldom see occasional -EIO errors because
the request send loop now times out. The current loop does 10 retries,
and inside vio_ldc_send() a further 1000 1usec retries are done as well.
Even with 10.5 msec of busy loop retries that's apparently not enough to
always succeed.
Rather than introduce continued busy looping, requeue the request and
have the delayed queue kicking retry the request after another 10ms.
This obviously isn't ideal, but there's seemingly no way to wait for
this type of event. And if 10ms of busy looping was not enough to make
progress, then presumably this is an edge condition and we just need to
guarantee to make forward progress at some later point in time. That's
more suitably done through letting the CPU tend to other work, rather
than sitting in a tight loop retrying.
[stian: rebased on top of the cookie-unmap fix, without which every
requeued attempt leaks LDC map table entries; tested on an
UltraSPARC T4 LDOM where the vdc_tx_trigger failure condition was
reproduced and absorbed by the requeue with no I/O error]
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/all/20251006100226.4246-2-glaubitz@physik.fu-berlin.de/
Link: https://lore.kernel.org/all/418310b3-2b77-4534-b2fd-27dcc11e333c@kernel.dk/
Signed-off-by: Stian Halseth <stian@itx.no>
Link: https://patch.msgid.link/20260901173947.3292110-3-stian@itx.no
Signed-off-by: Jens Axboe <axboe@kernel.dk>
__send_request() maps the request's pages into the LDC channel's map
table (ldc_map_sg()), fills in the descriptor and marks it
VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger().
When the trigger fails, the error path only prints a message: the
descriptor stays READY and the cookies are never unmapped. The
mapping is normally released in vdc_end_one() when the peer completes
the descriptor - but a descriptor whose doorbell was never sent will
never complete, and since dr->prod is not advanced on failure, the
reset path (vdc_requeue_inflight(), which walks [cons, prod)) never
visits it either. The map table entries are leaked permanently.
Since commit a11f6ca9ae ("sunvdc: Do not spin in an infinite loop
when vio_ldc_send() returns EAGAIN") trigger failures occur in
practice under load, so every resulting I/O error also leaks one
request's worth of entries from the fixed-size (8192 entries per
channel) map table. Because the allocator hands out contiguous
ranges, fragmentation makes large multi-segment requests fail first
as the table drains, until ldc_map_sg() fails permanently and the
disk is dead until reboot.
It also makes any retry-based recovery unusable: requeuing the
request on -EAGAIN remaps the pages on every attempt, overwriting
desc->cookies and orphaning the previous mapping, so the table
drains at the retry rate. This is the memory exhaustion observed
when the requeue approach was first tested in October 2025.
Roll back on failure: unmap the cookies, mark the descriptor FREE
again and clear the request entry. If the trigger failed with
-ENOTCONN, __vdc_tx_trigger() has already reset the port, which
tears down and reallocates both the dring and the LDC channel
including its map table - nothing to roll back, and the stale
descriptor must not be touched.
Fixes: a11f6ca9ae ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN")
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://github.com/sparclinux/issues/issues/2
Signed-off-by: Stian Halseth <stian@itx.no>
Link: https://patch.msgid.link/20260901173947.3292110-2-stian@itx.no
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Commit 14b007e178 added an address check using iter_iov_addr() and a
length check using iter_iov_len() to iov_iter_extract_bvecs(), but these
cannot be used so and are unsafe in this circumstance as the functions have
hardwired assumptions about the iterator type. They should only be used
with ITER_UBUF or ITER_IOVEC-type iterators; they shouldn't be used with
ITER_BVEC, ITER_KVEC, ITER_FOLIOQ, ITER_XARRAY or ITER_DISCARD iterators.
This proves to be a problem for cachefiles as an iterator of type
ITER_FOLIOQ is passed and iter_iov_addr() and iter_iov_len() both
malfunction because iter->__iov in iter_iov() is not pointing to an iovec
array.
Fix this by using iov_iter_alignment() instead.
Fixes: 14b007e178 ("block: validate user space vectors during extraction")
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
cc: Hannes Reinecke <hare@kernel.org>
cc: Christoph Hellwig <hch@infradead.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: Alexander Viro <viro@zeniv.linux.org.uk>
cc: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-block@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/1667275.1788941191@warthog.procyon.org.uk
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Every ublk test script sources test_common.sh from its own directory:
. "$(cd "$(dirname "$0")" && pwd)"/test_common.sh
and test_generic_02/12 additionally run bpftrace against the scripts in
trace/. Neither test_common.sh nor trace/ is listed in TEST_FILES, so
"make install" does not copy them into the install directory and every
ublk test fails when run from there:
./test_generic_02.sh: line 4: .../kselftest_install/ublk/test_common.sh: No such file or directory
./test_generic_02.sh: line 8: _have_program: command not found
The bpftrace tests are affected even when bpftrace is installed: the
missing trace/*.bt makes bpftrace exit immediately, and the tests then
report a skip rather than a failure, which hides the problem.
Add both to TEST_FILES, matching how other selftests ship their sourced
helpers (see kexec/kexec_common_lib.sh and zram/zram_lib.sh).
Fixes: 6aecda00b7 ("selftests: ublk: add kernel selftests for ublk")
Fixes: 723977cab4 ("selftests: ublk: add generic_01 for verifying sequential IO order")
Cc: stable@vger.kernel.org # v6.15+
Assisted-by: Kiro:claude-opus-5
Signed-off-by: Mahmoud Nagy Adam <mngyadam@amazon.de>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260909132602.68852-2-mngyadam@amazon.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The SuperBlitter operations derive an integer byte count per pixel. The
accelerated fill path handles only one-, two- and four-byte pixels.
However, the operations are currently installed for every external
framebuffer in SuperVidel RAM, including planar 1/2/4/8-bpp and 24-bpp
truecolor modes accepted by the external video parser.
For 1/2/4-bpp modes, the byte count becomes zero, so accelerated copies do
nothing and fills fall through to 32-bit stores. Planar 8-bpp uses an
incompatible memory layout. For 24-bpp modes, fills also use 32-bit stores
despite advancing addresses by three bytes per pixel. These cases can
corrupt the framebuffer beyond the requested rectangle.
Enable the SuperBlitter operations only for the layouts they implement:
8-bpp packed pixels and 16/32-bpp truecolor. Keep the existing software
operations for all other external formats.
Fixes: d463633d63 ("fbdev: atafb: Add support for SuperVidel's SuperBlitter")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Tested-by: Miro Kropáček <miro.kropacek@gmail.com>
Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
device_get_match_data() can return NULL, e.g. when the device is matched
through the I2C device ID table rather than the OF match table. The
returned value is stored in par->device_info and later dereferenced when
initializing par->vcomh, causing a NULL pointer dereference.
Check the return value right after the assignment and bail out with
-ENODEV (releasing the already allocated framebuffer) before any
dereference.
Signed-off-by: Yang Zi <2959243019@qq.com>
Signed-off-by: Helge Deller <deller@gmx.de>
