OESA-2025-1539

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

bpf: track changespktdata property for global functions

When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program:

__attribute__((__noinline__))
long skb_pull_data(struct __sk_buff *sk, __u32 len)
{
    return bpf_skb_pull_data(sk, len);
}

SEC("tc")
int test_invalidate_checks(struct __sk_buff *sk)
{
    int *p = (void *)(long)sk->data;
    if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;
    skb_pull_data(sk, 0);
    *p = 42;
    return TCX_PASS;
}

After a call to bpfskbpulldata() the pointer 'p' can't be used safely. See function filter.c:bpfhelperchangespkt_data() for a list of such helpers.

At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier.

This commit fixes the omission by computing field bpfsubproginfo->changespktdata for each sub-program before main verification pass. changespktdata should be set if: - subprogram calls helper for which bpfhelperchangespktdata returns true; - subprogram calls a global function, for which bpfsubproginfo->changespktdata should be set.

The verifier.c:checkcfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by checkcfg() and absence of recursive function calls: - checkcfg() would eventually visit every call to subprogram S in a state when S is fully explored; - when S is fully explored: - every direct helper call within S is explored (and thus changespktdata is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changespkt_data from S1).

The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changespktdata computation.(CVE-2024-58098)

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: validate ltreedepth to avoid out-of-bounds access

The ltreedepth field is 16-bit (_le16), but the actual maximum depth is limited to OCFS2MAXPATHDEPTH.

Add a check to prevent out-of-bounds access if ltreedepth has an invalid value, which may occur when reading from a corrupted mounted disk [1].(CVE-2025-22079)

In the Linux kernel, the following vulnerability has been resolved:

mfd: ene-kb3930: Fix a potential NULL pointer dereference

The offgpios could be NULL. Add missing check in the kb3930probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference").

This was detected by our static analysis tool.(CVE-2025-23146)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix kmemleak warning for percpu hashmap

Vlad Poenaru reported the following kmemleak issue:

unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpuallocnoprof+0x730/0xeb0 bpfmapallocpercpu+0x69/0xc0 preallocinit+0x9d/0x1b0 htabmapalloc+0x363/0x510 mapcreate+0x215/0x3a0 _sysbpf+0x16b/0x3e0 _x64sysbpf+0x18/0x20 dosyscall64+0x7b/0x150 entrySYSCALL64afterhwframe+0x4b/0x53

Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htabelemsetptr(): *(void _percpu **)(l->key + key_size) = pptr;

Note that the whole htabelem alignment is 8 (for x8664). If the keysize is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scanblock() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.

In htabmapalloc(), we already have

    htab->elem_size = sizeof(struct htab_elem) +
                      round_up(htab->map.key_size, 8);
    if (percpu)
            htab->elem_size += sizeof(void *);
    else
            htab->elem_size += round_up(htab->map.value_size, 8);

So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.

The issue can be reproduced with bpf selftest as well: 1. Enable CONFIGDEBUGKMEMLEAK config 2. Add a getchar() before skel destroy in testhashmap() in progtests/foreach.c. The purpose is to keep map available so kmemleak can be detected. 3. run './testprogs -t foreach/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Return NULL from hugepteoffset() for invalid PMD

LoongArch's hugepteoffset() currently returns a pointer to a PMD slot even if the underlying entry points to invalidptetable (indicating no mapping). Callers like smapshugetlbrange() fetch this invalid entry value (the address of invalidptetable) via this pointer.

The generic isswappte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!ptepresent() && !ptenone()" conditions. This misinterpretation, combined with a coincidental match by ismigrationentry() on the address bits, leads to kernel crashes in pfnswapentrytopage().

Fix this at the architecture level by modifying hugepteoffset() to check the PMD entry's content using pmdnone() before returning. If the entry is invalid (i.e., it points to invalidpte_table), return NULL instead of the pointer to the slot.(CVE-2025-37818)

In the Linux kernel, the following vulnerability has been resolved:

cpufreq: scmi: Fix null-ptr-deref in scmicpufreqget_rate()

cpufreqcpugetraw() can return NULL when the target CPU is not present in the policy->cpus mask. scmicpufreqgetrate() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after cpufreqcpuget_raw() to prevent this issue.(CVE-2025-37830)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: prevent hang on link training fail

[Why] When link training fails, the phy clock will be disabled. However, in enable_streams, it is assumed that link training succeeded and the mux selects the phy clock, causing a hang when a register write is made.

[How] When enable_stream is hit, check if link training failed. If it did, fall back to the ref clock to avoid a hang and keep the system in a recoverable state.(CVE-2025-37870)

In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix WARNON(!ctx) in _free_event() for partial init

Move the getctx(childctx) call and the childevent->ctx assignment to occur immediately after the child event is allocated. Ensure that childevent->ctx is non-NULL before any subsequent error path within inheritevent calls freeevent(), satisfying the assumptions of the cleanup code.

Details:

There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression.

The code initially incremented refcount then assigned context immediately after the childevent was created. Later, an early validity check for childevent was added before the refcount/assignment. Even later, a WARNONONCE() cleanup check was added, assuming event->ctx is valid if the pmuctx is valid. The problem is that the WARNONONCE() could trigger after the initial check passed but before childevent->ctx was assigned, violating its precondition. The solution is to assign childevent->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARNON_ONCE().

To resolve it, defer the refcount update and childevent->ctx assignment directly after childevent->pmuctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmuctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in childctx to findgetpmucontext before its refcount/assignment.

mingo: Expanded the changelog from another email by Gabriel Shahrouzi.

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix deadlock between rcutaskstrace and event_mutex.

Fix the following deadlock: CPU A freeevent() perfkprobedestroy() mutexlock(&eventmutex) perftraceeventunreg() synchronizercutaskstrace()

There are several paths where freeevent() grabs eventmutex and calls syncrcutaskstrace. Above is one such case.

CPU B bpfprogtestrunsyscall() rcureadlocktrace() bpfprogrunpinoncpu() bpfprogload() bpftracingfuncproto() tracesetclrevent() mutexlock(&eventmutex)

Delegate tracesetclr_event() to workqueue to avoid such lock dependency.(CVE-2025-37884)

In the Linux kernel, the following vulnerability has been resolved:

tracing: Verify event formats that have "%*p.."

The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory.

The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well.

Also add to the sample code a use case of "%*pbl".(CVE-2025-37938)