deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-37862
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: pidff: Fix null pointer dereference in pidff_find_fields

This function triggered a null pointer dereference if used to search for
a report that isn't implemented on the device. This happened both for
optional and required reports alike.

The same logic was applied to pidff_find_special_field and although
pidff_init_fields should return an error earlier if one of the required
reports is missing, future modifications could change this logic and
resurface this possible null pointer dereference again.

LKML bug report:
https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/22a05462c3d0eee15154faf8d13c49e6295270a5; https://git.kernel.org/stable/c/3a507184f9307e19cb441b897c49e7843c94e56b; https://git.kernel.org/stable/c/44a1b8b2027afbb37e418993fb23561bdb9efb38
CVE: CVE-2025-37863
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: don't allow datadir only

In theory overlayfs could support upper layer directly referring to a data
layer, but there's no current use case for this.

Originally, when data-only layers were introduced, this wasn't allowed,
only introduced by the "datadir+" feature, but without actually handling
this case, resulting in an Oops.

Fix by disallowing datadir without lowerdir.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0874b629f65320778e7e3e[PII_REDACTED]66d9db18; https://git.kernel.org/stable/c/21d2ffb0e9838a175064c22f3a9de97d1f56f27d; https://git.kernel.org/stable/c/b9e3579213ba648fa23f780e8d53e99011c62331
CVE: CVE-2025-37864
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: clean up FDB, MDB, VLAN entries on unbind

As explained in many places such as commit b117e1e8a86d ("net: dsa:
delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given
the assumption that higher layers have balanced additions/deletions.
As such, it only makes sense to be extremely vocal when those
assumptions are violated and the driver unbinds with entries still
present.

But Ido Schimmel points out a very simple situation where that is wrong:
https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/
(also briefly discussed by me in the aforementioned commit).

Basically, while the bridge bypass operations are not something that DSA
explicitly documents, and for the majority of DSA drivers this API
simply causes them to go to promiscuous mode, that isn't the case for
all drivers. Some have the necessary requirements for bridge bypass
operations to do something useful - see dsa_switch_supports_uc_filtering().

Although in tools/testing/selftests/net/forwarding/local_termination.sh,
we made an effort to popularize better mechanisms to manage address
filters on DSA interfaces from user space - namely macvlan for unicast,
and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the
fact is that 'bridge fdb add ... self static local' also exists as
kernel UAPI, and might be useful to someone, even if only for a quick
hack.

It seems counter-productive to block that path by implementing shim
.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP
in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from
running, although we could do that.

Accepting that cleanup is necessary seems to be the only option.
Especially since we appear to be coming back at this from a different
angle as well. Russell King is noticing that the WARN_ON() triggers even
for VLANs:
https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/

What happens in the bug report above is that dsa_port_do_vlan_del() fails,
then the VLAN entry lingers on, and then we warn on unbind and leak it.

This is not a straight revert of the blamed commit, but we now add an
informational print to the kernel log (to still have a way to see
that bugs exist), and some extra comments gathered from past years'
experience, to justify the logic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/7afb5fb42d4950f33af2732b8147c552659f79b7; https://git.kernel.org/stable/c/86c6613a69bca815f1865ed8cedfd4b9142621ab; https://git.kernel.org/stable/c/8fcc1e6f808912977caf17366c625b95dc29ba4f
CVE: CVE-2025-37865
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported

Russell King reports that on the ZII dev rev B, deleting a bridge VLAN
from a user port fails with -ENOENT:
https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/

This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(),
which tries to find an MST entry in &chip->msts associated with the SID,
but fails and returns -ENOENT as such.

But we know that this chip does not support MST at all, so that is not
surprising. The question is why does the guard in mv88e6xxx_mst_put()
not exit early:

	if (!sid)
		return 0;

And the answer seems to be simple: the sid comes from vlan.sid which
supposedly was previously populated by mv88e6xxx_vtu_get().
But some chip->info->ops->vtu_getnext() implementations do not populate
vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,
later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is
just residual stack memory.

Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge
VLAN mapped to the default MSTI. For some chips, SID 0 is valid and
installed by mv88e6xxx_stu_setup(). A chip which does not support the
STU would implicitly only support mapping all VLANs to the default MSTI,
so although SID 0 is not valid, it would be sufficient, if we were to
zero-initialize the vlan structure, to fix the bug, due to the
coincidence that a test for vlan.sid == 0 already exists and leads to
the same (correct) behavior.

Another option which would be sufficient would be to add a test for
mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one
which already exists in mv88e6xxx_mst_get(). But that placement means
the caller will have to dereference vlan.sid, which means it will access
uninitialized memory, which is not nice even if it ignores it later.

So we end up making both modifications, in order to not rely just on the
sid == 0 coincidence, but also to avoid having uninitialized structure
fields which might get temporarily accessed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/35cde75c08a1fa1a5ac0467afe2709caceeef002; https://git.kernel.org/stable/c/9da4acbd60664271d34a627f7f63cd5bad8eba74; https://git.kernel.org/stable/c/9ee6d3a368ed34f2457863da3085c676e9e37a3d
CVE: CVE-2025-37866
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show()

A warning is seen when running the latest kernel on a BlueField SOC:
[251.512704] ------------[ cut here ]------------
[251.512711] invalid sysfs_emit: buf:[PII_REDACTED]aa32ae
[251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8

The warning is triggered because the mlxbf-bootctl driver invokes
"sysfs_emit()" with a buffer pointer that is not aligned to the
start of the page. The driver should instead use "sysfs_emit_at()"
to support non-zero offsets into the destination buffer.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5e1dcc5bfd7a2896178c604bc69d6ab9650967da; https://git.kernel.org/stable/c/b129005ddfc0e6daf04a6d3b928a9e474f9b3918
CVE: CVE-2025-37867
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Silence oversized kvmalloc() warning

syzkaller triggered an oversized kvmalloc() warning.
Silence it by adding __GFP_NOWARN.

syzkaller log:
 WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180
 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180
 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246
 RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffffff8149d46b
 RDX: [PII_REDACTED] RSI: ffff8881030fae80 RDI: [PII_REDACTED]
 RBP: 000000712c800000 R08: [PII_REDACTED] R09: [PII_REDACTED]
 R10: ffffc90001e67c10 R11: 0030ae[PII_REDACTED] R12: [PII_REDACTED]
 R13: [PII_REDACTED] R14: 00000000ffffffff R15: [PII_REDACTED]
 FS:  00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: [PII_REDACTED] CR3:[PII_REDACTED]eb4005 CR4:[PII_REDACTED]3706b0
 DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
 DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
 Call Trace:
  <TASK>
  ib_umem_odp_get+0x1f6/0x390
  mlx5_ib_reg_user_mr+0x1e8/0x450
  ib_uverbs_reg_mr+0x28b/0x440
  ib_uverbs_write+0x7d3/0xa30
  vfs_write+0x1ac/0x6c0
  ksys_write+0x134/0x170
  ? __sanitizer_cov_trace_pc+0x1c/0x50
  do_syscall_64+0x50/0x110
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d81bb58a203ad5f4044dc18cfbc230c194f650a; https://git.kernel.org/stable/c/6c588e9afbab240c921f936cb676dac72e2e2b66; https://git.kernel.org/stable/c/791daf8240cedf27af8794038ae1d32ef643bce6
CVE: CVE-2025-37868
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/userptr: fix notifier vs folio deadlock

User is reporting what smells like notifier vs folio deadlock, where
migrate_pages_batch() on core kernel side is holding folio lock(s) and
then interacting with the mappings of it, however those mappings are
tied to some userptr, which means calling into the notifier callback and
grabbing the notifier lock. With perfect timing it looks possible that
the pages we pulled from the hmm fault can get sniped by
migrate_pages_batch() at the same time that we are holding the notifier
lock to mark the pages as accessed/dirty, but at this point we also want
to grab the folio locks(s) to mark them as dirty, but if they are
contended from notifier/migrate_pages_batch side then we deadlock since
folio lock won't be dropped until we drop the notifier lock.

Fortunately the mark_page_accessed/dirty is not really needed in the
first place it seems and should have already been done by hmm fault, so
just remove it.

(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2577b202458cddff85cc154b1fe7f313e0d1f418; https://git.kernel.org/stable/c/65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5; https://git.kernel.org/stable/c/90574ecf6052be83971d91d16600c5cf07003bbb
CVE: CVE-2025-37869
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Use local fence in error path of xe_migrate_clear

The intent of the error path in xe_migrate_clear is to wait on locally
generated fence and then return. The code is waiting on m->fence which
could be the local fence but this is only stable under the job mutex
leading to a possible UAF. Fix code to wait on local fence.

(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/20659d3150f1a2a258a173fe011013178ff2a197; https://git.kernel.org/stable/c/2ac5f466f62892a7d1ac2d1a3eb6cd14efbe2f2d; https://git.kernel.org/stable/c/dc712938aa26b001f448d5e93f59d57fa80f2dbd
CVE: CVE-2025-37870
Published: 2025-05-09
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0363c03672cd3191f037905bf981eb523a3b71b1; https://git.kernel.org/stable/c/04bf4f2a497e9877c425c5124652e61fb8a1a0aa; https://git.kernel.org/stable/c/8058061ed9d6bc259d1e678607b07d259342c08f
CVE: CVE-2025-37871
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: decrease sc_count directly if fail to queue dl_recall

A deadlock warning occurred when invoking nfs4_put_stid following a failed
dl_recall queue operation:
            T1                            T2
                                nfs4_laundromat
                                 nfs4_get_client_reaplist
                                  nfs4_anylock_blockers
__break_lease
 spin_lock // ctx->flc_lock
                                   spin_lock // clp->cl_lock
                                   nfs4_lockowner_has_blockers
                                    locks_owner_has_blockers
                                     spin_lock // flctx->flc_lock
 nfsd_break_deleg_cb
  nfsd_break_one_deleg
   nfs4_put_stid
    refcount_dec_and_lock
     spin_lock // clp->cl_lock

When a file is opened, an nfs4_delegation is allocated with sc_count
initialized to 1, and the file_lease holds a reference to the delegation.
The file_lease is then associated with the file through kernel_setlease.

The disassociation is performed in nfsd4_delegreturn via the following
call chain:
nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg -->
nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease
The corresponding sc_count reference will be released after this
disassociation.

Since nfsd_break_one_deleg executes while holding the flc_lock, the
disassociation process becomes blocked when attempting to acquire flc_lock
in generic_delete_lease. This means:
1) sc_count in nfsd_break_one_deleg will not be decremented to 0;
2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to
acquire cl_lock;
3) Consequently, no deadlock condition is created.

Given that sc_count in nfsd_break_one_deleg remains non-zero, we can
safely perform refcount_dec on sc_count directly. This approach
effectively avoids triggering deadlock warnings.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/14985d66b9b99c12995dd99d1c6c8dec4114c2a5; https://git.kernel.org/stable/c/7d192e27a431026c58d60edf66dc6cd98d0c01fc; https://git.kernel.org/stable/c/a1d14d931bf700c1025db8c46d6731aa5cf440f9
CVE: CVE-2025-37872
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

net: txgbe: fix memory leak in txgbe_probe() error path

When txgbe_sw_init() is called, memory is allocated for wx->rss_key
in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent
error paths after txgbe_sw_init() don't free the rss_key. Fix that by
freeing it in error path along with wx->mac_table.

Also change the label to which execution jumps when txgbe_sw_init()
fails, because otherwise, it could lead to a double free for rss_key,
when the mac_table allocation fails in wx_sw_init().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/635863d93deb8e352d63a8eba852efeaf1ac3539; https://git.kernel.org/stable/c/837197a722919f5b0eeb967fe7cb0cc1e83173b9; https://git.kernel.org/stable/c/b2727326d0a53709380aa147018085d71a6d4843
CVE: CVE-2025-37873
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: fix missing ring index trim on error path

Commit under Fixes converted tx_prod to be free running but missed
masking it on the Tx error path. This crashes on error conditions,
for example when DMA mapping fails.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/12f2d033fae957d84c2c0ce604d2a077e61fa2c0; https://git.kernel.org/stable/c/21e70f694bc0dcb40174b0940cc52a7769fc19e0; https://git.kernel.org/stable/c/3742c55de00266fa7c8fd2c5d61a453d223a9cd1
CVE: CVE-2025-37874
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ngbe: fix memory leak in ngbe_probe() error path

When ngbe_sw_init() is called, memory is allocated for wx->rss_key
in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent
error paths after ngbe_sw_init() don't free the rss_key. Fix that by
freeing it in error path along with wx->mac_table.

Also change the label to which execution jumps when ngbe_sw_init()
fails, because otherwise, it could lead to a double free for rss_key,
when the mac_table allocation fails in wx_sw_init().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/397487338eff1891c4654ce7deaafbf72a1688b2; https://git.kernel.org/stable/c/7c2b66a31c7a4866400f7e6fb43cb32021bfca01; https://git.kernel.org/stable/c/8335a3feb9d0d97e5e8f76d38b6bb8573d5b4a29
CVE: CVE-2025-37875
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

igc: fix PTM cycle trigger logic

Writing to clear the PTM status 'valid' bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM 'trigger' and status after each PTM transaction.

The issue can be reproduced with the following:

$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m

Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.

PHC2SYS exits with:

"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction
  fails

This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.

The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.

When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn't handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.

With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c03e4fbe1321697d9d04587e21e416705e1b19f; https://git.kernel.org/stable/c/16194ca3f3b4448a062650c869a7b3b206c6f5d3; https://git.kernel.org/stable/c/31959e06143692f7e02b8eef7d7d6ac645637906
CVE: CVE-2025-37877
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu: Clear iommu-dma ops on cleanup

If iommu_device_register() encounters an error, it can end up tearing
down already-configured groups and default domains, however this
currently still leaves devices hooked up to iommu-dma (and even
historically the behaviour in this area was at best inconsistent across
architectures/drivers...) Although in the case that an IOMMU is present
whose driver has failed to probe, users cannot necessarily expect DMA to
work anyway, it's still arguable that we should do our best to put
things back as if the IOMMU driver was never there at all, and certainly
the potential for crashing in iommu-dma itself is undesirable. Make sure
we clean up the dev->dma_iommu flag along with everything else.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/104a84276821aed0ed241ce0d82d6c3267e3fcb8; https://git.kernel.org/stable/c/280e5a[PII_REDACTED]6a4305ce0118e0aa9b866f12; https://git.kernel.org/stable/c/b14d98641312d972bb3f38e82eddf[PII_REDACTED]9
CVE: CVE-2025-37878
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init

Move the get_ctx(child_ctx) call and the child_event->ctx assignment to
occur immediately after the child event is allocated. Ensure that
child_event->ctx is non-NULL before any subsequent error path within
inherit_event calls free_event(), 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 child_event was created. Later, an early
validity check for child_event was added before the
refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was
added, assuming event->ctx is valid if the pmu_ctx is valid.
The problem is that the WARN_ON_ONCE() could trigger after the initial
check passed but before child_event->ctx was assigned, violating its
precondition. The solution is to assign child_event->ctx right after
its initial validation. This ensures the context exists for any
subsequent checks or cleanup routines, resolving the WARN_ON_ONCE().

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

[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c; https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e; https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7
CVE: CVE-2025-37879
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

9p/net: fix improper handling of bogus negative read/write replies

In p9_client_write() and p9_client_read_once(), if the server
incorrectly replies with success but a negative write/read count then we
would consider written (negative) <= rsize (positive) because both
variables were signed.

Make variables unsigned to avoid this problem.

The reproducer linked below now fails with the following error instead
of a null pointer deref:
9pnet: bogus RWRITE count[PII_REDACTED] > 3)
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/374e4cd75617c8c2552f562f39dd989583f5c330; https://git.kernel.org/stable/c/468ff4a7c61fb811c596a7c44b6a5455e40fd12b; https://git.kernel.org/stable/c/a68768e280b7d0c967ea509e791bb9b90adc94a5
CVE: CVE-2025-37880
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

um: work around sched_yield not yielding in time-travel mode

sched_yield by a userspace may not actually cause scheduling in
time-travel mode as no time has passed. In the case seen it appears to
be a badly implemented userspace spinlock in ASAN. Unfortunately, with
time-travel it causes an extreme slowdown or even deadlock depending on
the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS).

Work around it by accounting time to the process whenever it executes a
sched_yield syscall.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/887c5c12e80c8424bd471122d2e8b6b462e12874; https://git.kernel.org/stable/c/990ddc65173776f1e01e7135d8c1fd5f8fd4d5d2