deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-35872
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/secretmem: fix GUP-fast succeeding on secretmem folios

folio_is_secretmem() currently relies on secretmem folios being LRU
folios, to save some cycles.

However, folios might reside in a folio batch without the LRU flag set, or
temporarily have their LRU flag cleared.  Consequently, the LRU flag is
unreliable for this purpose.

In particular, this is the case when secretmem_fault() allocates a fresh
page and calls filemap_add_folio()->folio_add_lru().  The folio might be
added to the per-cpu folio batch and won't get the LRU flag set until the
batch was drained using e.g., lru_add_drain().

Consequently, folio_is_secretmem() might not detect secretmem folios and
GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel
when we would later try reading/writing to the folio, because the folio
has been unmapped from the directmap.

Fix it by removing that unreliable check.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/201e4aaf405dfd1308da[PII_REDACTED]3004c579b5; https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8; https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
CVE: CVE-2024-35873
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix vector state restore in rt_sigreturn()

The RISC-V Vector specification states in "Appendix D: Calling
Convention for Vector State" [1] that "Executing a system call causes
all caller-saved vector registers (v0-v31, vl, vtype) and vstart to
become unspecified.". In the RISC-V kernel this is called "discarding
the vstate".

Returning from a signal handler via the rt_sigreturn() syscall, vector
discard is also performed. However, this is not an issue since the
vector state should be restored from the sigcontext, and therefore not
care about the vector discard.

The "live state" is the actual vector register in the running context,
and the "vstate" is the vector state of the task. A dirty live state,
means that the vstate and live state are not in synch.

When vectorized user_from_copy() was introduced, an bug sneaked in at
the restoration code, related to the discard of the live state.

An example when this go wrong:

  1. A userland application is executing vector code
  2. The application receives a signal, and the signal handler is
     entered.
  3. The application returns from the signal handler, using the
     rt_sigreturn() syscall.
  4. The live vector state is discarded upon entering the
     rt_sigreturn(), and the live state is marked as "dirty", indicating
     that the live state need to be synchronized with the current
     vstate.
  5. rt_sigreturn() restores the vstate, except the Vector registers,
     from the sigcontext
  6. rt_sigreturn() restores the Vector registers, from the sigcontext,
     and now the vectorized user_from_copy() is used. The dirty live
     state from the discard is saved to the vstate, making the vstate
     corrupt.
  7. rt_sigreturn() returns to the application, which crashes due to
     corrupted vstate.

Note that the vectorized user_from_copy() is invoked depending on the
value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which
means that vlen has to be larger than 128b for this bug to trigger.

The fix is simply to mark the live state as non-dirty/clean prior
performing the vstate restore.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5b16d904e910183181b9d90efa957c787a8ac91b; https://git.kernel.org/stable/c/c27fa53b858b4ee6552a719aa599c250cf98a586; https://git.kernel.org/stable/c/5b16d904e910183181b9d90efa957c787a8ac91b
CVE: CVE-2024-35874
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

aio: Fix null ptr deref in aio_complete() wakeup

list_del_init_careful() needs to be the last access to the wait queue
entry - it effectively unlocks access.

Previously, finish_wait() would see the empty list head and skip taking
the lock, and then we'd return - but the completion path would still
attempt to do the wakeup after the task_struct pointer had been
overwritten.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9678bcc6234d83759fe091c197f5017a32b468da; https://git.kernel.org/stable/c/caeb4b0a11b3393e43f7fa8e0a5a18462acc66bd; https://git.kernel.org/stable/c/9678bcc6234d83759fe091c197f5017a32b468da
CVE: CVE-2024-35875
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/coco: Require seeding RNG with RDRAND on CoCo systems

There are few uses of CoCo that don't rely on working cryptography and
hence a working RNG. Unfortunately, the CoCo threat model means that the
VM host cannot be trusted and may actively work against guests to
extract secrets or manipulate computation. Since a malicious host can
modify or observe nearly all inputs to guests, the only remaining source
of entropy for CoCo guests is RDRAND.

If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
is meant to gracefully continue on gathering entropy from other sources,
but since there aren't other sources on CoCo, this is catastrophic.
This is mostly a concern at boot time when initially seeding the RNG, as
after that the consequences of a broken RDRAND are much more
theoretical.

So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
fails, panic(). This will also trigger if the system is booted without
RDRAND, as RDRAND is essential for a safe CoCo boot.

Add this deliberately to be "just a CoCo x86 driver feature" and not
part of the RNG itself. Many device drivers and platforms have some
desire to contribute something to the RNG, and add_device_randomness()
is specifically meant for this purpose.

Any driver can call it with seed data of any quality, or even garbage
quality, and it can only possibly make the quality of the RNG better or
have no effect, but can never make it worse.

Rather than trying to build something into the core of the RNG, consider
the particular CoCo issue just a CoCo issue, and therefore separate it
all out into driver (well, arch/platform) code.

  [ bp: Massage commit message. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e; https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374; https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5
CVE: CVE-2024-35876
Published: 2024-05-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35878
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

of: module: prevent NULL pointer dereference in vsnprintf()

In of_modalias(), we can get passed the str and len parameters which would
cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr
when the length is also 0. Also, we need to filter out the negative values
of the len parameter as these will result in a really huge buffer since
snprintf() takes size_t parameter while ours is ssize_t...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898; https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987; https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b
CVE: CVE-2024-35879
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

of: dynamic: Synchronize of_changeset_destroy() with the devlink removals

In the following sequence:
  1) of_platform_depopulate()
  2) of_overlay_remove()

During the step 1, devices are destroyed and devlinks are removed.
During the step 2, OF nodes are destroyed but
__of_changeset_entry_destroy() can raise warnings related to missing
of_node_put():
  ERROR: memory leak, expected refcount 1 instead of 2 ...

Indeed, during the devlink removals performed at step 1, the removal
itself releasing the device (and the attached of_node) is done by a job
queued in a workqueue and so, it is done asynchronously with respect to
function calls.
When the warning is present, of_node_put() will be called but wrongly
too late from the workqueue job.

In order to be sure that any ongoing devlink removals are done before
the of_node destruction, synchronize the of_changeset_destroy() with the
devlink removals.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a; https://git.kernel.org/stable/c/3ee[PII_REDACTED]d882e1ddd75333ca9c32879908c; https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951
CVE: CVE-2024-35880
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/kbuf: hold io_buffer_list reference over mmap

If we look up the kbuf, ensure that it doesn't get unregistered until
after we're done with it. Since we're inside mmap, we cannot safely use
the io_uring lock. Rely on the fact that we can lookup the buffer list
under RCU now and grab a reference to it, preventing it from being
unregistered until we're done with it. The lookup returns the
io_buffer_list directly with it referenced.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/561e4f9451d65fc2f7eef564e0064373e3019793; https://git.kernel.org/stable/c/5fd8e[PII_REDACTED]e0b5329a05f02d10a9eb91eb9; https://git.kernel.org/stable/c/65938e81df2197203bda4b9a0c477e7987218d66
CVE: CVE-2024-35881
Published: 2024-05-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35882
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP

Jan Schunk reports that his small NFS servers suffer from memory
exhaustion after just a few days. A bisect shows that commit
e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single
sock_sendmsg() call") is the first bad commit.

That commit assumed that sock_sendmsg() releases all the pages in
the underlying bio_vec array, but the reality is that it doesn't.
svc_xprt_release() releases the rqst's response pages, but the
record marker page fragment isn't one of those, so it is never
released.

This is a narrow fix that can be applied to stable kernels. A
more extensive fix is in the works.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861; https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8; https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882
CVE: CVE-2024-35883
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe

In function pci1xxxx_spi_probe, there is a potential null pointer that
may be caused by a failed memory allocation by the function devm_kzalloc.
Hence, a null pointer check needs to be added to prevent null pointer
dereferencing later in the code.

To fix this issue, spi_bus->spi_int[iter] should be checked. The memory
allocated by devm_kzalloc will be automatically released, so just directly
return -ENOMEM without worrying about memory leaks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1f886a7bfb3faf4c1021e73f045538008ce7634e; https://git.kernel.org/stable/c/4b31a226097cf8cc3c9de5e855d97757fdb2bf06; https://git.kernel.org/stable/c/95e5d9eb26705a9a76d2ef8bcba9ee2e195d653d
CVE: CVE-2024-35884
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

udp: do not accept non-tunnel GSO skbs landing in a tunnel

When rx-udp-gro-forwarding is enabled UDP packets might be GROed when
being forwarded. If such packets might land in a tunnel this can cause
various issues and udp_gro_receive makes sure this isn't the case by
looking for a matching socket. This is performed in
udp4/6_gro_lookup_skb but only in the current netns. This is an issue
with tunneled packets when the endpoint is in another netns. In such
cases the packets will be GROed at the UDP level, which leads to various
issues later on. The same thing can happen with rx-gro-list.

We saw this with geneve packets being GROed at the UDP level. In such
case gso_size is set; later the packet goes through the geneve rx path,
the geneve header is pulled, the offset are adjusted and frag_list skbs
are not adjusted with regard to geneve. When those skbs hit
skb_fragment, it will misbehave. Different outcomes are possible
depending on what the GROed skbs look like; from corrupted packets to
kernel crashes.

One example is a BUG_ON[1] triggered in skb_segment while processing the
frag_list. Because gso_size is wrong (geneve header was pulled)
skb_segment thinks there is "geneve header size" of data in frag_list,
although it's in fact the next packet. The BUG_ON itself has nothing to
do with the issue. This is only one of the potential issues.

Looking up for a matching socket in udp_gro_receive is fragile: the
lookup could be extended to all netns (not speaking about performances)
but nothing prevents those packets from being modified in between and we
could still not find a matching socket. It's OK to keep the current
logic there as it should cover most cases but we also need to make sure
we handle tunnel packets being GROed too early.

This is done by extending the checks in udp_unexpected_gso: GSO packets
lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must
be segmented.

[1] kernel BUG at net/core/skbuff.c:4408!
    RIP: 0010:skb_segment+0xd2a/0xf70
    __udp_gso_segment+0xaa/0x560
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19; https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8; https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
CVE: CVE-2024-35887
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ax25: fix use-after-free bugs caused by ax25_ds_del_timer

When the ax25 device is detaching, the ax25_dev_device_down()
calls ax25_ds_del_timer() to cleanup the slave_timer. When
the timer handler is running, the ax25_ds_del_timer() that
calls del_timer() in it will return directly. As a result,
the use-after-free bugs could happen, one of the scenarios
is shown below:

      (Thread 1)          |      (Thread 2)
                          | ax25_ds_timeout()
ax25_dev_device_down()    |
  ax25_ds_del_timer()     |
    del_timer()           |
  ax25_dev_put() //FREE   |
                          |  ax25_dev-> //USE

In order to mitigate bugs, when the device is detaching, use
timer_shutdown_sync() to stop the timer.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b; https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9; https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89
CVE: CVE-2024-35889
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: fix kernel panic on unknown packet types

In the very rare case where a packet type is unknown to the driver,
idpf_rx_process_skb_fields would return early without calling
eth_type_trans to set the skb protocol / the network layer handler.
This is especially problematic if tcpdump is running when such a
packet is received, i.e. it would cause a kernel panic.

Instead, call eth_type_trans for every single packet, even when
the packet type is unknown.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b4d28f7fa4dd531cf503a4fe1ca7008960cc5832; https://git.kernel.org/stable/c/dd19e827d63ac60debf117676d1126bff884bdb8; https://git.kernel.org/stable/c/b4d28f7fa4dd531cf503a4fe1ca7008960cc5832
CVE: CVE-2024-35890
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

gro: fix ownership transfer

If packets are GROed with fraglist they might be segmented later on and
continue their journey in the stack. In skb_segment_list those skbs can
be reused as-is. This is an issue as their destructor was removed in
skb_gro_receive_list but not the reference to their socket, and then
they can't be orphaned. Fix this by also removing the reference to the
socket.

For example this could be observed,

  kernel BUG at include/linux/skbuff.h:3131!  (skb_orphan)
  RIP: 0010:ip6_rcv_core+0x11bc/0x19a0
  Call Trace:
   ipv6_list_rcv+0x250/0x3f0
   __netif_receive_skb_list_core+0x49d/0x8f0
   netif_receive_skb_list_internal+0x634/0xd40
   napi_complete_done+0x1d2/0x7d0
   gro_cell_poll+0x118/0x1f0

A similar construction is found in skb_gro_receive, apply the same
change there.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2eeab8c47c3c0276e0746bc382f405c9a236a5ad; https://git.kernel.org/stable/c/5b3b67f731296027cceb3efad881ae281213f86f; https://git.kernel.org/stable/c/d225b0ac96dc40d7e8ae2bc227eb2c56e130975f
CVE: CVE-2024-35891
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: micrel: Fix potential null pointer dereference

In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may
return NULL as ptp_header due to abnormal packet type or corrupted packet.
Fix this bug by adding ptp_header check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]c2768f53426642f78a42bcaaa53e8; https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc; https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4
CVE: CVE-2024-35894
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: prevent BPF accessing lowat from a subflow socket.

Alexei reported the following splat:

 WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0
 Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)]
 CPU: 32 PID: 3276 Comm: test_progs Tainted: GO       6.8.0-12873-g2c43c33bfd23
 Call Trace:
  <TASK>
  mptcp_set_rcvlowat+0x79/0x1d0
  sk_setsockopt+0x6c0/0x1540
  __bpf_setsockopt+0x6f/0x90
  bpf_sock_ops_setsockopt+0x3c/0x90
  bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b
  bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132
  bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86
  __cgroup_bpf_run_filter_sock_ops+0xbc/0x250
  tcp_connect+0x879/0x1160
  tcp_v6_connect+0x50c/0x870
  mptcp_connect+0x129/0x280
  __inet_stream_connect+0xce/0x370
  inet_stream_connect+0x36/0x50
  bpf_trampoline_[PII_REDACTED]+0x49/0xef
  inet_stream_connect+0x5/0x50
  __sys_connect+0x63/0x90
  __x64_sys_connect+0x14/0x20

The root cause of the issue is that bpf allows accessing mptcp-level
proto_ops from a tcp subflow scope.

Fix the issue detecting the problematic call and preventing any action.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/3ffb1ab698376f09cc33101c07c1be229389fe29; https://git.kernel.org/stable/c/ee3c845787b621cfe82c2e52c513024a9d7a78f5; https://git.kernel.org/stable/c/fcf4692fa39e86a590c14a4af2de704e1d20a3b5
CVE: CVE-2024-35895
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Prevent lock inversion deadlock in map delete elem

syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:

       CPU0                    CPU1
       ----                    ----
  lock(&htab->buckets[i].lock);
                               local_irq_disable();
                               lock(&host->lock);
                               lock(&htab->buckets[i].lock);
  <Interrupt>
    lock(&host->lock);

Locks in sockmap are hardirq-unsafe by design. We expects elements to be
deleted from sockmap/sockhash only in task (normal) context with interrupts
enabled, or in softirq context.

Detect when map_delete_elem operation is invoked from a context which is
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
error.

Note that map updates are not affected by this issue. BPF verifier does not
allow updating sockmap/sockhash from a BPF tracing program today.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/668b3074aa14829e2ac[PII_REDACTED]a93b60fef86; https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd; https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5
CVE: CVE-2024-35897
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: discard table flag update with pending basechain deletion

Hook unregistration is deferred to the commit phase, same occurs with
hook updates triggered by the table dormant flag. When both commands are
combined, this results in deleting a basechain while leaving its hook
still registered in the core.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1bc83a019bbe268be[PII_REDACTED]ec28c2458a518; https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4; https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb
CVE: CVE-2024-35898
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()

nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
And thhere is not any protection when iterate over nf_tables_flowtables
list in __nft_flowtable_type_get(). Therefore, there is pertential
data-race of nf_tables_flowtables list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
nft_flowtable_type_get() to protect the entire type query process.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304; https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8; https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007