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

serial: mxs-auart: add spinlock around changing cts state

The uart_handle_cts_change() function in serial_core expects the caller
to hold uport->lock. For example, I have seen the below kernel splat,
when the Bluetooth driver is loaded on an i.MX28 board.

    [   85.119255] ------------[ cut here ]------------
    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
    [   85.151396] Hardware name: Freescale MXS (Device Tree)
    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
    (...)
    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
    (...)
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0dc0637e6b16158af[PII_REDACTED]1bfd0151adb37; https://git.kernel.org/stable/c/21535ef0ac[PII_REDACTED]fe3e4347ea498205c99a; https://git.kernel.org/stable/c/2c9b943e9924cf1269e44289bc5e60e51b0f5270
CVE: CVE-2024-27001
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: vmk80xx: fix incomplete endpoint checking

While vmk80xx does have endpoint checking implemented, some things
can fall through the cracks. Depending on the hardware model,
URBs can have either bulk or interrupt type, and current version
of vmk80xx_find_usb_endpoints() function does not take that fully
into account. While this warning does not seem to be too harmful,
at the very least it will crash systems with 'panic_on_warn' set on
them.

Fix the issue found by Syzkaller [1] by somewhat simplifying the
endpoint checking process with usb_find_common_endpoints() and
ensuring that only expected endpoint types are present.

This patch has not been tested on real hardware.

[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
 <TASK>
 usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
 vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
...

Similar issue also found by Syzkaller:
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9; https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696; https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f669069d2
CVE: CVE-2024-27002
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: Do a runtime PM get on controllers during probe

mt8183-mfgcfg has a mutual dependency with genpd during the probing
stage, which leads to a deadlock in the following call stack:

CPU0:  genpd_lock --> clk_prepare_lock
genpd_power_off_work_fn()
 genpd_lock()
 generic_pm_domain::power_off()
    clk_unprepare()
      clk_prepare_lock()

CPU1: clk_prepare_lock --> genpd_lock
clk_register()
  __clk_core_init()
    clk_prepare_lock()
    clk_pm_runtime_get()
      genpd_lock()

Do a runtime PM get at the probe function to make sure clk_register()
won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,
do this on all mediatek clock controller probings because we don't
believe this would cause any regression.

Verified on MT8183 and MT8192 Chromebooks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8; https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3; https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5
CVE: CVE-2024-27003
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: Get runtime PM before walking tree for clk_summary

Similar to the previous commit, we should make sure that all devices are
runtime resumed before printing the clk_summary through debugfs. Failure
to do so would result in a deadlock if the thread is resuming a device
to print clk state and that device is also runtime resuming in another
thread, e.g the screen is turning on and the display driver is starting
up. We remove the calls to clk_pm_runtime_{get,put}() in this path
because they're superfluous now that we know the devices are runtime
resumed. This also squashes a bug where the return value of
clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow
on error paths.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e; https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0; https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321
CVE: CVE-2024-27005
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

interconnect: Don't access req_list while it's being manipulated

The icc_lock mutex was split into separate icc_lock and icc_bw_lock
mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.

The icc_set_bw() function will eventually iterate over req_list while
only holding icc_bw_lock, but req_list can be modified while only
holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),
and icc_put().

Example A:

  CPU0                               CPU1
  ----                               ----
  icc_set_bw(path_a)
    mutex_lock(&icc_bw_lock);
                                     icc_put(path_b)
                                       mutex_lock(&icc_lock);
    aggregate_requests()
      hlist_for_each_entry(r, ...
                                       hlist_del(...
        <r = invalid pointer>

Example B:

  CPU0                               CPU1
  ----                               ----
  icc_set_bw(path_a)
    mutex_lock(&icc_bw_lock);
                                     path_b = of_icc_get()
                                       of_icc_get_by_index()
                                         mutex_lock(&icc_lock);
                                         path_find()
                                           path_init()
    aggregate_requests()
      hlist_for_each_entry(r, ...
                                             hlist_add_head(...
        <r = invalid pointer>

Fix this by ensuring icc_bw_lock is always held before manipulating
icc_node::req_list. The additional places icc_bw_lock is held don't
perform any memory allocations, so we should still be safe from the
original lockdep splats that motivated the separate locks.

[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-362, CWE-667
References: https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d; https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6; https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
CVE: CVE-2024-27006
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()

The count field in struct trip_stats, representing the number of times
the zone temperature was above the trip point, needs to be incremented
in thermal_debug_tz_trip_up(), for two reasons.

First, if a trip point is crossed on the way up for the first time,
thermal_debug_update_temp() called from update_temperature() does
not see it because it has not been added to trips_crossed[] array
in the thermal zone's struct tz_debugfs object yet.  Therefore, when
thermal_debug_tz_trip_up() is called after that, the trip point's
count value is 0, and the attempt to divide by it during the average
temperature computation leads to a divide error which causes the kernel
to crash.  Setting the count to 1 before the division by incrementing it
fixes this problem.

Second, if a trip point is crossed on the way up, but it has been
crossed on the way up already before, its count value needs to be
incremented to make a record of the fact that the zone temperature is
above the trip now.  Without doing that, if the mitigations applied
after crossing the trip cause the zone temperature to drop below its
threshold, the count will not be updated for this episode at all and
the average temperature in the trip statistics record will be somewhat
higher than it should be.

Cc :6.8+ <stable@vger.kernel.org> # 6.8+
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9c8215d32e730b597c809a9d2090bf8ec1b79fcf; https://git.kernel.org/stable/c/b552f63cd43735048bbe9bfbb7a9dcfce166fbdd; https://git.kernel.org/stable/c/9c8215d32e730b597c809a9d2090bf8ec1b79fcf
CVE: CVE-2024-27007
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: change src_folio after ensuring it's unpinned in UFFDIO_MOVE

Commit d7a08838ab74 ("mm: userfaultfd: fix unexpected change to src_folio
when UFFDIO_MOVE fails") moved the src_folio->{mapping, index} changing to
after clearing the page-table and ensuring that it's not pinned.  This
avoids failure of swapout+migration and possibly memory corruption.

However, the commit missed fixing it in the huge-page case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/c0205eaf3af9f5db14d4b5ee4abacf4a583c3c50; https://git.kernel.org/stable/c/df5f6e683e7f21a15d8be6e7a0c7a46436963ebe; https://git.kernel.org/stable/c/c0205eaf3af9f5db14d4b5ee4abacf4a583c3c50
CVE: CVE-2024-27008
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: nv04: Fix out of bounds access

When Output Resource (dcb->or) value is assigned in
fabricate_dcb_output(), there may be out of bounds access to
dac_users array in case dcb->or is zero because ffs(dcb->or) is
used as index there.
The 'or' argument of fabricate_dcb_output() must be interpreted as a
number of bit to set, not value.

Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062; https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a84f579a5; https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1
CVE: CVE-2024-27009
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/cio: fix race condition during online processing

A race condition exists in ccw_device_set_online() that can cause the
online process to fail, leaving the affected device in an inconsistent
state. As a result, subsequent attempts to set that device online fail
with return code ENODEV.

The problem occurs when a path verification request arrives after
a wait for final device state completed, but before the result state
is evaluated.

Fix this by ensuring that the CCW-device lock is held between
determining final state and checking result state.

Note that since:

commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")

path verification requests are much more likely to occur during boot,
resulting in an increased chance of this race condition occurring.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/2d8527f2f911fab84aec04df4788c0c23af3df48; https://git.kernel.org/stable/c/2df56f4ea769ff81e51bbb[PII_REDACTED]3bde9c49; https://git.kernel.org/stable/c/3076b3c38a704e10df5e143c213653309d532538
CVE: CVE-2024-27010
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: Fix mirred deadlock on device recursion

When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.

[..... other info removed for brevity....]
[   82.890906]
[   82.890906] ============================================
[   82.890906] WARNING: possible recursive locking detected
[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W
[   82.890906] --------------------------------------------
[   82.890906] ping/418 is trying to acquire lock:
[   82.890906] ffff[PII_REDACTED]10 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] but task is already holding lock:
[   82.890906] ffff[PII_REDACTED]10 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] other info that might help us debug this:
[   82.890906]  Possible unsafe locking scenario:
[   82.890906]
[   82.890906]        CPU0
[   82.890906]        ----
[   82.890906]   lock(&sch->q.lock);
[   82.890906]   lock(&sch->q.lock);
[   82.890906]
[   82.890906]  *** DEADLOCK ***
[   82.890906]
[..... other info removed for brevity....]

Example setup (eth0->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

Another example(eth0->eth1->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth1

tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11; https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef; https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11
CVE: CVE-2024-27011
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: fix memleak in map from abort path

The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.

Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.

[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: [PII_REDACTED] RBX: ffff888125bffb28 RCX: dffffc[PII_REDACTED]
[ 6170.287912] RDX: [PII_REDACTED] RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: [PII_REDACTED] R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead[PII_REDACTED]22 R15: dead[PII_REDACTED]00
[ 6170.287940] FS:  [PII_REDACTED](0000) GS:ffff888390b00000(0000) knlGS:[PII_REDACTED]
[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 6170.287955] CR2: 00007fd31fc00710 CR3:[PII_REDACTED]f60004 CR4:[PII_REDACTED]1706f0
[ 6170.287962] Call Trace:
[ 6170.287967]  <TASK>
[ 6170.287973]  ? __warn+0x9f/0x1a0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.288104]  ? handle_bug+0x3c/0x70
[ 6170.288112]  ? exc_invalid_op+0x17/0x40
[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/49d0e656d19dfb2d4d7c230e4a720d37b3decff6; https://git.kernel.org/stable/c/86a1471d7cde792941109b93b558b5dc078b9ee9; https://git.kernel.org/stable/c/a1bd2a38a1c6388fc8556816dc203c3e9dc52237
CVE: CVE-2024-27013
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

tun: limit printing rate when illegal packet received by tun dev

vhost_worker will call tun call backs to receive packets. If too many
illegal packets arrives, tun_do_read will keep dumping packet contents.
When console is enabled, it will costs much more cpu time to dump
packet and soft lockup will be detected.

net_ratelimit mechanism can be used to limit the dumping rate.

PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: "vhost-32980"
 #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
 #3 [fffffe00003fced0] do_nmi at ffffffff8922660d
 #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
    [exception RIP: io_serial_in+20]
    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002
    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: [PII_REDACTED]
    RDX:[PII_REDACTED]0003fd  RSI: [PII_REDACTED]  RDI: ffffffff8af428a0
    RBP: [PII_REDACTED]   R8: [PII_REDACTED]   R9:[PII_REDACTED]00000f
    R10: [PII_REDACTED]  R11: ffffffff8acbf64f  R12: [PII_REDACTED]
    R13: ffffffff8acbf698  R14: [PII_REDACTED]  R15: [PII_REDACTED]
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594
 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124
 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
 #12 [ffffa65531497b68] printk at ffffffff89318306
 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
 #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
 #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
 #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
 #18 [ffffa65531497f10] kthread at ffffffff892d2e72
 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421; https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad; https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3
CVE: CVE-2024-27015
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: incorrect pppoe tuple

pppoe traffic reaching ingress path does not match the flowtable entry
because the pppoe header is expected to be at the network header offset.
This bug causes a mismatch in the flow table lookup, so pppoe packets
enter the classical forwarding path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4ed82dd368ad883dc[PII_REDACTED]b882f044e625d; https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27; https://git.kernel.org/stable/c/e3f[PII_REDACTED]42fcd5f05c5e70777feb10f000d
CVE: CVE-2024-27016
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: validate pppoe header

Ensure there is sufficient room to access the protocol field of the
PPPoe header. Validate it once before the flowtable lookup, then use a
helper function to access protocol field.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf; https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7; https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9
CVE: CVE-2024-27017
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress.
The pipapo set backend walk iterator cannot rely on it to infer what
view of the datastructure is to be used. Add notation to specify if user
wants to read/update the set.

Based on patch from Florian Westphal.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/29b359cf6d95fd60730533f7f10464e95bd17c73; https://git.kernel.org/stable/c/52735a010f37580b3a569a996f878fdd87425650; https://git.kernel.org/stable/c/721715655c72640567e[PII_REDACTED]c99801148ed
CVE: CVE-2024-27019
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

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

nft_unregister_obj() can concurrent with __nft_obj_type_get(),
and there is not any protection when iterate over nf_tables_objects
list in __nft_obj_type_get(). Therefore, there is potential data-race
of nf_tables_objects list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_objects
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
nft_obj_type_get() to protect the entire type query process.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920; https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73; https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e
CVE: CVE-2024-27020
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

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

nft_unregister_expr() can concurrent with __nft_expr_type_get(),
and there is not any protection when iterate over nf_tables_expressions
list in __nft_expr_type_get(). Therefore, there is potential data-race
of nf_tables_expressions list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
nft_expr_type_get() to protect the entire type query process.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f; https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907; https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5