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

net: fix out-of-bounds access in ops_init

net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.

Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7; https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25eac29c42; https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3
CVE: CVE-2024-36885
Published: 2024-05-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-36887
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

e1000e: change usleep_range to udelay in PHY mdic access

This is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround
for sporadic MDI error on Meteor Lake systems"). The referenced commit
used usleep_range inside the PHY access routines, which are sometimes
called from an atomic context. This can lead to a kernel panic in some
scenarios, such as cable disconnection and reconnection on vPro systems.

Solve this by changing the usleep_range calls back to udelay.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/387f295cb2150ed164905b648d76dfcbd3621778; https://git.kernel.org/stable/c/950d5226cd6bb83ba720961a8d4d5cf79e6afd57; https://git.kernel.org/stable/c/f8a139656c95db893a543159873c57a470d7376d
CVE: CVE-2024-36888
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

workqueue: Fix selection of wake_cpu in kick_pool()

With cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following
kernel oops was observed:

smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 8 CPUs
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: [PII_REDACTED] TEID: [PII_REDACTED]
[..]
 Call Trace:
arch_vcpu_is_preempted+0x12/0x80
select_idle_sibling+0x42/0x560
select_task_rq_fair+0x29a/0x3b0
try_to_wake_up+0x38e/0x6e0
kick_pool+0xa4/0x198
__queue_work.part.0+0x2bc/0x3a8
call_timer_fn+0x36/0x160
__run_timers+0x1e2/0x328
__run_timer_base+0x5a/0x88
run_timer_softirq+0x40/0x78
__do_softirq+0x118/0x388
irq_exit_rcu+0xc0/0xd8
do_ext_irq+0xae/0x168
ext_int_handler+0xbe/0xf0
psw_idle_exit+0x0/0xc
default_idle_call+0x3c/0x110
do_idle+0xd4/0x158
cpu_startup_entry+0x40/0x48
rest_init+0xc6/0xc8
start_kernel+0x3c4/0x5e0
startup_continue+0x3c/0x50

The crash is caused by calling arch_vcpu_is_preempted() for an offline
CPU. To avoid this, select the cpu with cpumask_any_and_distribute()
to mask __pod_cpumask with cpu_online_mask. In case no cpu is left in
the pool, skip the assignment.

tj: This doesn't fully fix the bug as CPUs can still go down between picking
the target CPU and the wake call. Fixing that likely requires adding
cpu_online() test to either the sched or s390 arch code. However, regardless
of how that is fixed, workqueue shouldn't be picking a CPU which isn't
online as that would result in unpredictable and worse behavior.
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/57a01eafdcf78f6da34fad9ff075ed5dfdd9f420; https://git.kernel.org/stable/c/6d559e70b3eb6623935cbe7f94c1912c1099777b; https://git.kernel.org/stable/c/c57824d4fe07c2131f8c48687cbd5ee2be60c767
CVE: CVE-2024-36889
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: ensure snd_nxt is properly initialized on connect

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
  RAX: [PII_REDACTED] RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: [PII_REDACTED]
  RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
  R10: [PII_REDACTED] R11: fefefefefefefeff R12: ffff888138ba8000
  R13: [PII_REDACTED] R14: ffff8881029bd908 R15: ffff[PII_REDACTED]00
  FS:  [PII_REDACTED](0000) GS:ffff88813bd00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 00007f604a5dae38 CR3:[PII_REDACTED]dac002 CR4:[PII_REDACTED]170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
   kthread+0x121/0x170 kernel/kthread.c:388
   ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012; https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe; https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4
CVE: CVE-2024-36890
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/slab: make __free(kfree) accept error pointers

Currently, if an automatically freed allocation is an error pointer that
will lead to a crash.  An example of this is in wm831x_gpio_dbg_show().

   171	char *label __free(kfree) = gpiochip_dup_line_label(chip, i);
   172	if (IS_ERR(label)) {
   173		dev_err(wm831x->dev, "Failed to duplicate label\n");
   174		continue;
   175  }

The auto clean up function should check for error pointers as well,
otherwise we're going to keep hitting issues like this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-763
References: https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543; https://git.kernel.org/stable/c/946771c2a2b1150f9b7286feadc3aa1e15a1eb16; https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2
CVE: CVE-2024-36891
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

maple_tree: fix mas_empty_area_rev() null pointer dereference

Currently the code calls mas_start() followed by mas_data_end() if the
maple state is MA_START, but mas_start() may return with the maple state
node == NULL.  This will lead to a null pointer dereference when checking
information in the NULL node, which is done in mas_data_end().

Avoid setting the offset if there is no node by waiting until after the
maple state is checked for an empty or single entry state.

A user could trigger the events to cause a kernel oops by unmapping all
vmas to produce an empty maple tree, then mapping a vma that would cause
the scenario described above.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6c9c7c1e63b198a8b979ad963eb21410f10ccb00; https://git.kernel.org/stable/c/883e5d542bbdddbddeba60250cb482baf3ae2415; https://git.kernel.org/stable/c/955a923d[PII_REDACTED]ff574270f81510112be9cf
CVE: CVE-2024-36892
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/slub: avoid zeroing outside-object freepointer for single free

Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing
separately") splits single and bulk object freeing in two functions
slab_free() and slab_free_bulk() which leads slab_free() to call
slab_free_hook() directly instead of slab_free_freelist_hook().

If `init_on_free` is set, slab_free_hook() zeroes the object.
Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are
set, the do_slab_free() slowpath executes freelist consistency
checks and try to decode a zeroed freepointer which leads to a
"Freepointer corrupt" detection in check_object().

During bulk free, slab_free_freelist_hook() isn't affected as it always
sets it objects freepointer using set_freepointer() to maintain its
reconstructed freelist after `init_on_free`.

For single free, object's freepointer thus needs to be avoided when
stored outside the object if `init_on_free` is set. The freepointer left
as is, check_object() may later detect an invalid pointer value due to
objects overflow.

To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the
command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.

dmesg sample log:
[   10.708715] =============================================================================
[   10.710323] BUG kmalloc-rnd-05-32 (Tainted: G    B           T ): Freepointer corrupt
[   10.712695] -----------------------------------------------------------------------------
[   10.712695]
[   10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x[PII_REDACTED]00a00(workingset|slab|node=0|zone=2)
[   10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c
[   10.716698]
[   10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.720703] Object   ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.720703] Object   ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.724696] Padding  ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.724696] Padding  ffff9d9a8035667c: 00 00 00 00                                      ....
[   10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]5f6e82114b18c812edd57fd7970dcb; https://git.kernel.org/stable/c/8f828aa48812ced28aa39cb3cfe55ef2444d03dd; https://git.kernel.org/stable/c/[PII_REDACTED]5f6e82114b18c812edd57fd7970dcb
CVE: CVE-2024-36893
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: Check for port partner validity before consuming it

typec_register_partner() does not guarantee partner registration
to always succeed. In the event of failure, port->partner is set
to the error value or NULL. Given that port->partner validity is
not checked, this results in the following crash:

Unable to handle kernel NULL pointer dereference at virtual address xx
 pc : run_state_machine+0x1bc8/0x1c08
 lr : run_state_machine+0x1b90/0x1c08
..
 Call trace:
   run_state_machine+0x1bc8/0x1c08
   tcpm_state_machine_work+0x94/0xe4
   kthread_worker_fn+0x118/0x328
   kthread+0x1d0/0x23c
   ret_from_fork+0x10/0x20

To prevent the crash, check for port->partner validity before
derefencing it in all the call sites.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5; https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637; https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd
CVE: CVE-2024-36894
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:

    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --> dwc3_stop_active_transfers()
    --> dwc3_gadget_giveback(-ESHUTDOWN)
      --> ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --> usb_ep_free_request()            --> usb_ep_dequeue()

There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data->req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can
lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context.  Hence, leading
into a deadlock.

Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
to NULL after freeing it within the ffs->eps_lock.  This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.

This fix depends on
  commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
  consistently")
CVSS Score: 5.6 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19; https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a; https://git.kernel.org/stable/c/73c05ad46bb4fbbdb[PII_REDACTED]76d1c8dbcffbb
CVE: CVE-2024-36895
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: use correct buffer size when parsing configfs lists

This commit fixes uvc gadget support on 32-bit platforms.

Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for
reuse") introduced a helper function __uvcg_iter_item_entries() to aid
with parsing lists of items on configfs attributes stores. This function
is a generalization of another very similar function, which used a
stack-allocated temporary buffer of fixed size for each item in the list
and used the sizeof() operator to check for potential buffer overruns.
The new function was changed to allocate the now variably sized temp
buffer on heap, but wasn't properly updated to also check for max buffer
size using the computed size instead of sizeof() operator.

As a result, the maximum item size was 7 (plus null terminator) on
64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just
barely enough, 3 is definitely too small for some of UVC configfs
attributes. For example, dwFrameInteval, specified in 100ns units,
usually has 6-digit item values, e.g. 166666 for 60fps.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/650ae71c80749fc7cb8858c8049f532eaec64410; https://git.kernel.org/stable/c/7a54e5052bde582fd0e7677334fe7a5be92e242c; https://git.kernel.org/stable/c/a422089ce42ced73713e5032aad29a9a7cbe9528
CVE: CVE-2024-36896
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():
usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to
is concurrently removed, but the function does not check for this
possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev
is the parent of the port device, so it can be changed easily.  Adding a
check for hub == NULL prevents further problems.

The same bug exists in the disable_show() routine, and it can be fixed the
same way.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848; https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277; https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434
CVE: CVE-2024-36897
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Atom Integrated System Info v2_2 for DCN35

New request from KMD/VBIOS in order to support new UMA carveout
model. This fixes a null dereference from accessing
Ctx->dc_bios->integrated_info while it was NULL.

DAL parses through the BIOS and extracts the necessary
integrated_info but was missing a case for the new BIOS
version 2.3.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e[PII_REDACTED]e5c; https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a; https://git.kernel.org/stable/c/7e[PII_REDACTED]eb093165a31baff040d35446fb8b
CVE: CVE-2024-36898
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

gpiolib: cdev: fix uninitialised kfifo

If a line is requested with debounce, and that results in debouncing
in software, and the line is subsequently reconfigured to enable edge
detection then the allocation of the kfifo to contain edge events is
overlooked.  This results in events being written to and read from an
uninitialised kfifo.  Read events are returned to userspace.

Initialise the kfifo in the case where the software debounce is
already active.
CVSS Score: 7.8 (HIGH)
CWE: CWE-908
References: https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5; https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2; https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e
CVE: CVE-2024-36899
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

gpiolib: cdev: Fix use after free in lineinfo_changed_notify

The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.

Here is the typical stack when issue happened:

[free]
gpio_chrdev_release()
  --> bitmap_free(cdev->watched_lines)                  <-- freed
  --> blocking_notifier_chain_unregister()
    --> down_write(&nh->rwsem)                          <-- waiting rwsem
          --> __down_write_common()
            --> rwsem_down_write_slowpath()
                  --> schedule_preempt_disabled()
                    --> schedule()

[use]
st54spi_gpio_dev_release()
  --> gpio_free()
    --> gpiod_free()
      --> gpiod_free_commit()
        --> gpiod_line_state_notify()
          --> blocking_notifier_call_chain()
            --> down_read(&nh->rwsem);                  <-- held rwsem
            --> notifier_call_chain()
              --> lineinfo_changed_notify()
                --> test_bit(xxxx, cdev->watched_lines) <-- use after free

The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc[PII_REDACTED]52039da; https://git.kernel.org/stable/c/2d008d4961b039d2edce[PII_REDACTED]961b7e5fb5; https://git.kernel.org/stable/c/2dfbb920a89bdc58087672ad5325dc6c588b6860
CVE: CVE-2024-36900
Published: 2024-05-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when devlink reload during initialization

The devlink reload process will access the hardware resources,
but the register operation is done before the hardware is initialized.
So, processing the devlink reload during initialization may lead to kernel
crash.

This patch fixes this by registering the devlink after
hardware initialization.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095; https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd; https://git.kernel.org/stable/c/72ede790f5a03c[PII_REDACTED]a1b72ebce293a2e7