deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-10584
Published: 2024-12-24
Description: The DirectoryPress – Business Directory And Classified Ad Listing plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 3.6.16 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file. When DirectoryPress Frontend is installed, this can be exploited by unauthenticated users.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-434, CWE-434
References: https://plugins.trac.wordpress.org/changeset/3205071/directorypress/trunk/includes/directorypress_svg.php; https://www.wordfence.com/threat-intel/vulnerabilities/id/4625072b-815d-41d2-bf8f-ac290efde369?source=cve
CVE: CVE-2024-10856
Published: 2024-12-24
Description: The Booking Calendar WpDevArt plugin is vulnerable to time-based, blind SQL injection via the `id` parameter in the “wpdevart_booking_calendar” shortcode in versions up to, and including, 3.2.19 due to insufficient escaping on the user-supplied parameter and lack of sufficient preparation on the existing SQL query. The vulnerability requires the “delete_prev_date” theme option being enabled. This makes it possible for authenticated attackers, with contributor-level access or above, to append additional SQL queries into already existing query that can be used to extract sensitive information such as passwords from the database.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-89
References: https://plugins.trac.wordpress.org/browser/booking-calendar/tags/3.2.15/includes/main_class.php#L90; https://plugins.trac.wordpress.org/browser/booking-calendar/tags/3.2.15/includes/main_class.php#L91; https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3209851%40booking-calendar&new=3209851%40booking-calendar&sfp_email=&sfph_mail=
CVE: CVE-2024-11726
Published: 2024-12-24
Description: The Appointment Booking Calendar Plugin and Scheduling Plugin – BookingPress plugin for WordPress is vulnerable to SQL Injection via the 'category' parameter of the 'bookingpress_form' shortcode in all versions up to, and including, 1.1.21 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query.  This makes it possible for authenticated attackers, with Contributor-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-89
References: https://plugins.trac.wordpress.org/changeset/3206780/bookingpress-appointment-booking/trunk/core/classes/frontend/class.bookingpress_appointment_bookings.php; https://www.wordfence.com/threat-intel/vulnerabilities/id/6d081b89-1b98-4f4f-8728-d1ea676d7afd?source=cve
CVE: CVE-2024-12268
Published: 2024-12-24
Description: The Responsive Blocks – WordPress Gutenberg Blocks plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'responsive-block-editor-addons/portfolio' block in all versions up to, and including, 1.9.7 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVSS Score: 6.4 (MEDIUM)
CWE: CWE-79
References: https://plugins.trac.wordpress.org/changeset/3208350/responsive-block-editor-addons/tags/1.9.8/src/blocks/portfolio/index.php; https://www.wordfence.com/threat-intel/vulnerabilities/id/0e951b97-3d17-4360-8fec-393e2f0c13d2?source=cve
CVE: CVE-2024-43441
Published: 2024-12-24
Description: Authentication Bypass by Assumed-Immutable Data vulnerability in Apache HugeGraph-Server.

This issue affects Apache HugeGraph-Server: from 1.0.0 before 1.5.0.

Users are recommended to upgrade to version 1.5.0, which fixes the issue.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-302
References: https://lists.apache.org/thread/h2607yv32wgcrywov960jpxhvsmmlf12; http://www.openwall.com/lists/oss-security/2024/12/24/2
CVE: CVE-2024-53145
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

um: Fix potential integer overflow during physmem setup

This issue happens when the real map size is greater than LONG_MAX,
which can be easily triggered on UML/i386.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/1575df968650d11771359e5ac78278c5b0cc19f3; https://git.kernel.org/stable/c/1bd118c5f887802cef2d9ba0d[PII_REDACTED]f1cae; https://git.kernel.org/stable/c/5c710f45811e7e2bfcf703980c306f19c7e1ecfe
CVE: CVE-2024-53146
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: Prevent a potential integer overflow

If the tag length is >= U32_MAX - 3 then the "length + 4" addition
can result in an integer overflow. Address this by splitting the
decoding into several steps so that decode_cb_compound4res() does
not have to perform arithmetic on the unsafe length value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/084f797dbc7e52209a4ab6dbc7f[PII_REDACTED]eb9; https://git.kernel.org/stable/c/3c5f545c9a1f8a1869246f6f3ae8c17289d6a841; https://git.kernel.org/stable/c/745f7ce5a95e783ba62fe[PII_REDACTED]66aec2aa8
CVE: CVE-2024-53147
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix out-of-bounds access of directory entries

In the case of the directory size is greater than or equal to
the cluster size, if start_clu becomes an EOF cluster(an invalid
cluster) due to file system corruption, then the directory entry
where ei->hint_femp.eidx hint is outside the directory, resulting
in an out-of-bounds access, which may cause further file system
corruption.

This commit adds a check for start_clu, if it is an invalid cluster,
the file or directory will be treated as empty.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/184fa506e392eb78364d9283c961217ff2c0617b; https://git.kernel.org/stable/c/3ddd1cb2b458ff6a193bc845f408dfff217db29e; https://git.kernel.org/stable/c/a0120d[PII_REDACTED]539ef928cf067d02372efb8c
CVE: CVE-2024-53148
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: Flush partial mappings in error case

If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.

Fix it by explicitly flushing all mappings in our VMA on the error path.

See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/16c507df509113c037cdc0ba642b9ab3389bd26c; https://git.kernel.org/stable/c/297f14fbb81895f4ccdb0ad25d196786d6461e00; https://git.kernel.org/stable/c/57f048c2d205b85e34282a9b0b0ae177e84c2f44
CVE: CVE-2024-53149
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: glink: fix off-by-one in connector_status

UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.
Correct the condition in the pmic_glink_ucsi_connector_status()
callback, fixing Type-C orientation reporting for the third USB-C
connector.
CVSS Score: 4.6 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/4a[PII_REDACTED]0897393fa1776ea3877e4baf8cca; https://git.kernel.org/stable/c/6ba6f7f29e0dff47a2799e60dcd1b5c29cd811a5; https://git.kernel.org/stable/c/8a2273e5c1beb285729aa001422967b4711c53fe
CVE: CVE-2024-53150
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each
descriptor at traversing for clock descriptors.  That is, when a
device provides a bogus descriptor with a shorter bLength, the driver
might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator
functions for the clock descriptor traversal.  When the descriptor
length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just
check bLength against the sizeof() of each descriptor type.
OTOH, the clock selector descriptor of UAC2 and UAC3 has an array
of bNrInPins elements and two more fields at its tail, hence those
have to be checked in addition to the sizeof() check.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/096bb5b43edf755bc4477e64004fa3a20539ec2f; https://git.kernel.org/stable/c/45a92cbc88e4013bfed7fd2ccab3ade45f8e896b; https://git.kernel.org/stable/c/74cb86e1006c5437b1d90084d22018da30fddc77
CVE: CVE-2024-53151
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

svcrdma: Address an integer overflow

Dan Carpenter reports:
> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data
> structure") from Jun 22, 2020 (linux-next), leads to the following
> Smatch static checker warning:
>
>	net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()
>	warn: potential user controlled sizeof overflow 'segcount * 4 * 4'
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>     488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)
>     489 {
>     490         u32 segcount;
>     491         __be32 *p;
>     492
>     493         if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))
>                                                               ^^^^^^^^
>
>     494                 return false;
>     495
>     496         /* A bogus segcount causes this buffer overflow check to fail. */
>     497         p = xdr_inline_decode(&rctxt->rc_stream,
> --> 498                               segcount * rpcrdma_segment_maxsz * sizeof(*p));
>
>
> segcount is an untrusted u32.  On 32bit systems anything >= SIZE_MAX / 16 will
> have an integer overflow and some those values will be accepted by
> xdr_inline_decode().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/21e1cf688fb0397788c8dd42e1e0b08d58ac5c7b; https://git.kernel.org/stable/c/3c63d8946e578663b868cb9912dac616ea68bfd0; https://git.kernel.org/stable/c/4cbc3ba6dc2f746497cade60bcbaa82ae3696689
CVE: CVE-2024-53152
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()

Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.

All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.

One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.

Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/40e2125381dc[PII_REDACTED]e3eefdd25c6df5375; https://git.kernel.org/stable/c/70212c[PII_REDACTED]e986d95000d2745529cac9d7; https://git.kernel.org/stable/c/72034050ccf4202cd6558b0afd2474f756ea3b9b
CVE: CVE-2024-53153
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()

Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of qcom_pcie_perst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.

All of the Qcom endpoint SoCs supported as of now depend on the refclk from
the host for keeping the controller operational. Due to this limitation,
any access to the hardware registers in the absence of refclk will result
in a whole endpoint crash. Unfortunately, most of the controller cleanups
require accessing the hardware registers (like eDMA cleanup performed in
dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup
functions are currently causing the crash in the endpoint SoC once host
asserts PERST#.

One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host (as I was told by the Qcom engineers).

Thus, fix this crash by moving the controller cleanups to the start of
the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is
called whenever the host has deasserted PERST# and it is guaranteed that
the refclk would be active at this point. So at the start of this function
(after enabling resources), the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/516969d5765e2302d33b4f251496eedb757d55ea; https://git.kernel.org/stable/c/7d7cf89b119af433354f865fc01017b9f8aa411a; https://git.kernel.org/stable/c/e03b5f1615c84f4139cb53ef8659f4cdb8d6a563
CVE: CVE-2024-53154
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: clk-apple-nco: Add NULL check in applnco_probe

Add NULL check in applnco_probe, to handle kernel NULL pointer
dereference error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/066c14619e8379c1bafbbf8196fd38eac303472b; https://git.kernel.org/stable/c/534e02f83889ccef5fe6beb46e773ab9d4ae1655; https://git.kernel.org/stable/c/72ea9a7e9e260aa39f9d1c9254cf92adfb05c4f5
CVE: CVE-2024-53155
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix uninitialized value in ocfs2_file_read_iter()

Syzbot has reported the following KMSAN splat:

BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80
 ocfs2_file_read_iter+0x9a4/0xf80
 __io_read+0x8d4/0x20f0
 io_read+0x3e/0xf0
 io_issue_sqe+0x42b/0x22c0
 io_wq_submit_work+0xaf9/0xdc0
 io_worker_handle_work+0xd13/0x2110
 io_wq_worker+0x447/0x1410
 ret_from_fork+0x6f/0x90
 ret_from_fork_asm+0x1a/0x30

Uninit was created at:
 __alloc_pages_noprof+0x9a7/0xe00
 alloc_pages_mpol_noprof+0x299/0x990
 alloc_pages_noprof+0x1bf/0x1e0
 allocate_slab+0x33a/0x1250
 ___slab_alloc+0x12ef/0x35e0
 kmem_cache_alloc_bulk_noprof+0x486/0x1330
 __io_alloc_req_refill+0x84/0x560
 io_submit_sqes+0x172f/0x2f30
 __se_sys_io_uring_enter+0x406/0x41c0
 __x64_sys_io_uring_enter+0x11f/0x1a0
 x64_sys_call+0x2b54/0x3ba0
 do_syscall_64+0xcd/0x1e0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Since an instance of 'struct kiocb' may be passed from the block layer
with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'
and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in
'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/366c933c2ab34dd6551acc03b4872726b7605143; https://git.kernel.org/stable/c/66b7ddd1804e2c4216dd7ead8eeb746cdbb3b62f; https://git.kernel.org/stable/c/6c8f8d1e595dabd5389817f6d798cc8bd95c40ab
CVE: CVE-2024-53156
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()

I found the following bug in my fuzzer:

  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
  index 255 is out of range for type 'htc_endpoint [22]'
  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Workqueue: events request_firmware_work_func
  Call Trace:
   <TASK>
   dump_stack_lvl+0x180/0x1b0
   __ubsan_handle_out_of_bounds+0xd4/0x130
   htc_issue_send.constprop.0+0x20c/0x230
   ? _raw_spin_unlock_irqrestore+0x3c/0x70
   ath9k_wmi_cmd+0x41d/0x610
   ? mark_held_locks+0x9f/0xe0
   ...

Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/3fe99b9690b99606d3743c9961ebee865cfa1ab8; https://git.kernel.org/stable/c/5f177fb9d01355ac183e65ad8909ea8ef734e0cf; https://git.kernel.org/stable/c/70eae50d2156cb6e078d0d78809b49bf2f4c7540
CVE: CVE-2024-53157
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Check the DVFS OPP count returned by the firmware

Fix a kernel crash with the below call trace when the SCPI firmware
returns OPP count of zero.

dvfs_info.opp_count may be zero on some platforms during the reboot
test, and the kernel will crash after dereferencing the pointer to
kcalloc(info->count, sizeof(*opp), GFP_KERNEL).

  |  Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
  |  Mem abort info:
  |    ESR = 0x96000004
  |    Exception class = DABT (current EL), IL = 32 bits
  |    SET = 0, FnV = 0
  |    EA = 0, S1PTW = 0
  |  Data abort info:
  |    ISV = 0, ISS = 0x00000004
  |    CM = 0, WnR = 0
  |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
  |  [[PII_REDACTED]] pgd=[PII_REDACTED]
  |  Internal error: Oops: 96000004 [#1] SMP
  |  scpi-hwmon: probe of PHYT000D:00 failed with error -110
  |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
  |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
  |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
  |  pstate: 60000005 (nZCv daif -PAN -UAO)
  |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |  lr : clk_register+0x438/0x720
  |  Call trace:
  |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |   devm_clk_hw_register+0x50/0xa0
  |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
  |   scpi_clocks_probe+0x528/0x70c [clk_scpi]
  |   platform_drv_probe+0x58/0xa8
  |   really_probe+0x260/0x3d0
  |   driver_probe_device+0x12c/0x148
  |   device_driver_attach+0x74/0x98
  |   __driver_attach+0xb4/0xe8
  |   bus_for_each_dev+0x88/0xe0
  |   driver_attach+0x30/0x40
  |   bus_add_driver+0x178/0x2b0
  |   driver_register+0x64/0x118
  |   __platform_driver_register+0x54/0x60
  |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
  |   do_one_initcall+0x54/0x220
  |   do_init_module+0x54/0x1c8
  |   load_module+0x14a4/0x1668
  |   __se_sys_finit_module+0xf8/0x110
  |   __arm64_sys_finit_module+0x24/0x30
  |   el0_svc_common+0x78/0x170
  |   el0_svc_handler+0x38/0x78
  |   el0_svc+0x8/0x340
  |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
  |  ---[ end trace 06feb22469d89fa8 ]---
  |  Kernel panic - not syncing: Fatal exception
  |  SMP: stopping secondary CPUs
  |  Kernel Offset: disabled
  |  CPU features: 0x10,a0002008
  |  Memory Limit: none
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/025067eeb945aa17c7dd483a63960125b7efb577; https://git.kernel.org/stable/c/06258e57fee253f4046d3a6a86d7fde09f596eac; https://git.kernel.org/stable/c/109aa654f85c5141e813b2cd1bd36d90be678407
CVE: CVE-2024-53158
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()

This loop is supposed to break if the frequency returned from
clk_round_rate() is the same as on the previous iteration.  However,
that check doesn't make sense on the first iteration through the loop.
It leads to reading before the start of these->clk_perf_tbl[] array.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/351bb7f9ecb9d1f09bd7767491a2b8d07f4f1ea4; https://git.kernel.org/stable/c/37cdd4f0c266560b7b924c42361eeae3dc5f0c3e; https://git.kernel.org/stable/c/56eda41dcce0ec4d3418b4f85037bdea181486cc
CVE: CVE-2024-53159
Published: 2024-12-24
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-53160
Published: 2024-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu

KCSAN reports a data race when access the krcp->monitor_work.timer.expires
variable in the schedule_delayed_monitor_work() function:

<snip>
BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu

read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:
 schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]
 kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839
 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441
 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203
 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849
 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143
 __sys_bpf+0x2e5/0x7a0
 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]
 __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739
 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:
 __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173
 add_timer_global+0x51/0x70 kernel/time/timer.c:1330
 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523
 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552
 queue_delayed_work include/linux/workqueue.h:677 [inline]
 schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]
 kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310
 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391
 kthread+0x1d1/0x210 kernel/kthread.c:389
 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events_unbound kfree_rcu_monitor
<snip>

kfree_rcu_monitor() rearms the work if a "krcp" has to be still
offloaded and this is done without holding krcp->lock, whereas
the kvfree_call_rcu() holds it.

Fix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so
both functions do not race anymore.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/05b8ea1f16667f07c8e5843fb4bde3e49d49ead8; https://git.kernel.org/stable/c/5ced426d97ce84299ecfcc7bd8b38f975fd11089; https://git.kernel.org/stable/c/967a0e61910825d1fad009d836a6cb41f7402395