| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
tracing: Hold trace_types_lock when resetting last boot data from readers
update_last_data_if_empty() is called from tracing_open() with O_TRUNC,
tracing_read_pipe() and tracing_buffers_read() without trace_types_lock.
Two readers can both pass the LAST_BOOT test and free module_delta
twice, and a module notifier can update module_delta while it is being
freed.
Take trace_types_lock in those paths and keep the callers that already
hold it on an unlocked variant. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing: Save the event file instead of the compatible histogram
create_field_var_hist() creates a histogram on the matched event to
supply a field variable, and records it on the target so it can be torn
down later:
hist_data = find_compatible_hist(target_hist_data, file);
...
/* Save the compatible histogram information */
var_hist->hist_data = hist_data;
hist_data is not the histogram it creates. It is one that was already
there, whose keys the new one copies. The saved pointer has a single
user, unregister_field_var_hists(), which runs when the target is
removed:
file = hist_data->field_var_hists[i]->hist_data->event_file;
find_compatible_hist() matches on keys alone, so it can pick one with no
variables of its own. check_var_refs() then returns false and the user
can remove it while the target still points at it:
BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320
Read of size 8 at addr ffff8880093b90e0 by task init/1
Freed by task 1:
kfree+0x154/0x420
event_hist_trigger_free+0x1d5/0x320
event_hist_trigger_parse+0x35f3/0x69e0
trigger_process_regex+0x1a6/0x250
Save the event file instead. It is all the dereference ever wanted, and
it does not go away when the user removes a trigger. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Verify event_call identity when updating synth_event refcount
In event_hist_trigger_parse() and hist_unreg_all(), the histogram
registration and unregistration paths look up find_synth_event() using
trace_event_name(file->event_call) and adjust se->ref if a match is
found.
Because find_synth_event() only compares the event basename, registering
or removing a histogram on a non-synthetic trace event whose basename
matches a synthetic event erroneously modifies the synthetic event's
reference count. If a histogram is registered on the non-synthetic
event before the synthetic event is created and removed afterwards,
se->ref is decremented without a matching increment, allowing the
synthetic event to be freed while an active histogram action still holds
a pointer to it.
Introduce find_synth_event_call() to verify that &se->call matches
file->event_call before adjusting se->ref. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Mark syscall helpers as sleepable
bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes,
allocate with GFP_KERNEL, and wait for an RCU grace period.
bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as
well.
Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is
sleepable. That does not make every callback sleepable: a syscall program
can register a bpf_timer callback, and the verifier checks that callback
in a non-sleepable context while retaining the syscall helper set.
Without .might_sleep on the prototypes, such a callback can invoke
bpf_sys_bpf() from hrtimer softirq context and trigger a
scheduling-while-atomic failure. bpf_sys_close() is exposed through the
same missing context check.
Set .might_sleep on both prototypes so the existing helper-context check
rejects them from timer callbacks and other atomic regions. Calls from the
sleepable main body remain valid. |
| In the Linux kernel, the following vulnerability has been resolved:
printk: Postpone kthread startup
There have been various bug reports related to SMP systems hanging
on boot. The reports vary but seem to have some overlap with regard
to missed IPI's during SMP setup. The reports also show that
reverting NBCON console usage allows the bugs to disappear.
The NBCON kthreads for console printing are started very early
during boot using early_initcall(). Since these kthreads are
asynchronously enabling/disabling interrupts during early boot, they
may be interfering with early SMP setup on some hardware platforms.
Starting the console printing kthreads later has shown to avoid the
hanging on systems that could previously reproduce the issue.
Postpone kthread starting until after all arch initcalls have
completed. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: xiic: restore non-managed runtime PM to fix clk WARN flood
The devres conversion replaced manual pm_runtime_enable()/disable() with
devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime
PM teardown. The managed release tears runtime PM down in the wrong
order: it calls pm_runtime_dont_use_autosuspend() before
pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres
is LIFO so the devm_clk_get_enabled() release runs afterwards.
At remove(), pm_runtime_put_sync() leaves the device active with the
autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle()
suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the
clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s
the already-disabled clock, so clk_core_disable() WARNs ("clkN already
disabled") on every teardown.
Drop the managed helper and restore the non-managed runtime PM setup and
teardown, so runtime PM is enabled once in probe and disabled once in
remove and the clock enable count stays balanced.
Order the remove teardown so runtime PM is disabled before the usage
count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle()
instead of pm_runtime_put_sync(). Dropping the count first with autosuspend
still enabled arms the autosuspend timer, and a preemption before
pm_runtime_disable() lets it expire, suspend the device and clk_disable()
the clock, which the devm release then disables again - the same WARN.
Restore the non-managed IRQ request as well. The probe error paths now
unwind runtime PM by hand via goto, and a devm-registered handler is only
freed later during devres unwind, so it would stay live across the manual
teardown (and across any future failing step added after it). Request the
IRQ with request_threaded_irq() and free it explicitly in the probe error
path and in remove. The probe error path also clears use_autosuspend, to
match the teardown in remove(). |
| In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: Avoid infinite retry loop in init_vp_index()
There is a retry loop in init_vp_index() where the CPUs from a certain
node are stripped out if they have already been in the allocated cpumask
or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no
CPU left, the allocated cpumask is ignored and the process is retried
again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns
out not to contain any CPU in that particular node, that will become an
infinite retry loop. This particular problem was reported by sashiko
[1]. This should rarely happen, but we still need to guard against this.
Fix this infinite loop problem by also skipping NUMA node that has no
housekeeping CPU in the inner while loop of init_vp_index(). Also update
the early abort check to check for the absence of online housekeeping
CPUs instead of just the emptiness of the cpumask. As the outer for
loop will only be reached if the housekeeping cpumask has at least one
online CPU, a NUMA node with housekeeping CPUs will eventually be found. |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to cause a denial of service using a specially crafted regular expression that would cause excessive resource consumption. |
| IBM Concert 1.0.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. |
| IBM Concert 1.0.0 through 3.0.0 could allow a local attacker to obtain sensitive information due to recursive copying of build context directories into container images. |
| IBM Concert 1.0.0 through 3.0.0 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to cause a denial of service due to improper enforcement of storage limits. |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to access or modify unauthorized resources due to the use of wildcards in RBAC permission definitions. |
| IBM Concert 1.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files. |
| IBM Concert 1.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. |
| IBM Concert 1.0 through 3.0.0 is vulnerable to Improper Certificate Validation. |
| IBM Concert 1.0 through 3.0.0 is vulnerable to Information Disclosure via Heap Inspection. |
| IBM Concert 1.0 through 3.0.0 uses cross-origin resource sharing (CORS) which could allow an attacker to carry out privileged actions as the domain name is not being limited to only trusted domains. |
| IBM Concert 1.0 through 3.0.0 allows information disclosure through exposure of schema suggestions. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: shared: gracefully handle no-device lookup of shared GPIOs
We use platform lookup tables for shared GPIOs. This mechanism needs a
struct device to work so fwnode-based lookup with no device associated
currently causes a NULL-pointer deference.
Adding this functionality will require a larger rework and it has never
worked anyway so add a check that allows the kernel to gracefully handle
this situation with an error ahead of implementing that functionality as
a new feature. |
