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

vmxnet3: Fix missing reserved tailroom

Use rbi->len instead of rcd->len for non-dataring packet.

Found issue:
  XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom
  WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20
  CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O       6.5.1 #1
  RIP: 0010:xdp_warn+0xf/0x20
  ...
  ? xdp_warn+0xf/0x20
  xdp_do_redirect+0x15f/0x1c0
  vmxnet3_run_xdp+0x17a/0x400 [vmxnet3]
  vmxnet3_process_xdp+0xe4/0x760 [vmxnet3]
  ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3]
  vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3]
  vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3]
  __napi_poll+0x20/0x180
  net_rx_action+0x177/0x390
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7c8505ecc2d15473d679b8e06335434b84fffe86; https://git.kernel.org/stable/c/91d017d19d5a9ad153e2dc23ed3c0e2e79ef5262; https://git.kernel.org/stable/c/aba8659caf[PII_REDACTED]9feea06069f529329ea6
CVE: CVE-2024-27027
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

dpll: fix dpll_xa_ref_*_del() for multiple registrations

Currently, if there are multiple registrations of the same pin on the
same dpll device, following warnings are observed:
WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230
WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0

The problem is, that in both dpll_xa_ref_dpll_del() and
dpll_xa_ref_pin_del() registration is only removed from list in case the
reference count drops to zero. That is wrong, the registration has to
be removed always.

To fix this, remove the registration from the list and free
it unconditionally, instead of doing it only when the ref reference
counter reaches zero.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/769324eb[PII_REDACTED]2cdb15483cdaf4877bf661; https://git.kernel.org/stable/c/b27e32e9367dac024cd6f61f22655714f483fd67; https://git.kernel.org/stable/c/b446631f355ece73b13c311dd712c47381a23172
CVE: CVE-2024-27028
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: spi-mt65xx: Fix NULL pointer access in interrupt handler

The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
handler may end up writing to the invalid memory and cause crashes.

Add a check to trans->tx_buf before using it.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713; https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38; https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6
CVE: CVE-2024-27029
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix mmhub client id out-of-bounds access

Properly handle cid 0x140.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1f24b3040f2b6ffcb97151fabb[PII_REDACTED]d923; https://git.kernel.org/stable/c/6540ff6482c1a5a6890ae44b23d0852ba1986d9e; https://git.kernel.org/stable/c/e1e076bda4fd6378ae650f2c6ef1a4ff93c5aea5
CVE: CVE-2024-27030
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Use separate handlers for interrupts

For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44; https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701; https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c
CVE: CVE-2024-27032
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid potential panic during recovery

During recovery, if FAULT_BLOCK is on, it is possible that
f2fs_reserve_new_block() will return -ENOSPC during recovery,
then it may trigger panic.

Also, if fault injection rate is 1 and only FAULT_BLOCK fault
type is on, it may encounter deadloop in loop of block reservation.

Let's change as below to fix these issues:
- remove bug_on() to avoid panic.
- limit the loop count of block reservation to avoid potential
deadloop.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/21ec68234826b1b54ab980a8df6e33c74cfbee58; https://git.kernel.org/stable/c/8844b2f8a3f0c428b74672f9726f9950b1a7764c; https://git.kernel.org/stable/c/d034810d02a5af8eb74debe29877dcaf5f00fdd1
CVE: CVE-2024-27033
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic

verify_blkaddr() will trigger panic once we inject fault into
f2fs_is_valid_blkaddr(), fix to remove this unnecessary f2fs_bug_on().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]bfc8b50296d9e544ff91c4d52af2db; https://git.kernel.org/stable/c/6633cdc8b2ebefcddcfcdacfd063105e60f39a49; https://git.kernel.org/stable/c/abe98a05e7162f64759bf9111108ebcb11322dec
CVE: CVE-2024-27034
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix to cover normal cluster write with cp_rwsem

When we overwrite compressed cluster w/ normal cluster, we should
not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data
will be corrupted if partial blocks were persisted before CP & SPOR,
due to cluster metadata wasn't updated atomically.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b1b14d9fc94b8feae20808684c8af28ec80f45b; https://git.kernel.org/stable/c/52982edfcefd475cc34af663d5c47c0cddaa5739; https://git.kernel.org/stable/c/542c8b3c774a480bfd0804291a12f6f2391b0cd1
CVE: CVE-2024-27035
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix to guarantee persisting compressed blocks by CP

If data block in compressed cluster is not persisted with metadata
during checkpoint, after SPOR, the data may be corrupted, let's
guarantee to write compressed page by checkpoint.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/57e8b17d0522c8f4daf0c4d9969b4d[PII_REDACTED]; https://git.kernel.org/stable/c/82704e598d7b33c7e45526e34d3c585426319bed; https://git.kernel.org/stable/c/8a430dd49e9cb021372b0ad91e60aeef9c6ced00
CVE: CVE-2024-27036
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix writeback data corruption

cifs writeback doesn't correctly handle the case where
cifs_extend_writeback() hits a point where it is considering an additional
folio, but this would overrun the wsize - at which point it drops out of
the xarray scanning loop and calls xas_pause().  The problem is that
xas_pause() advances the loop counter - thereby skipping that page.

What needs to happen is for xas_reset() to be called any time we decide we
don't want to process the page we're looking at, but rather send the
request we are building and start a new one.

Fix this by copying and adapting the netfslib writepages code as a
temporary measure, with cifs writeback intending to be offloaded to
netfslib in the near future.

This also fixes the issue with the use of filemap_get_folios_tag() causing
retry of a bunch of pages which the extender already dealt with.

This can be tested by creating, say, a 64K file somewhere not on cifs
(otherwise copy-offload may get underfoot), mounting a cifs share with a
wsize of 64000, copying the file to it and then comparing the original file
and the copy:

        dd if=/dev/urandom of=/tmp/64K bs=64k count=1
        mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000
        cp /tmp/64K /mnt/64K
        cmp /tmp/64K /mnt/64K

Without the fix, the cmp fails at position 64000 (or shortly thereafter).
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/65f2ced695982ccd516196d0a9447d85dbe2eed5; https://git.kernel.org/stable/c/844b4e132f57f1333dc79feaa035075a096762e4; https://git.kernel.org/stable/c/e45deec35bf7f1f4f992a707b2d04a8c162f2240
CVE: CVE-2024-27037
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: zynq: Prevent null pointer dereference caused by kmalloc failure

The kmalloc() in zynq_clk_setup() will return null if the
physical memory has run out. As a result, if we use snprintf()
to write data to the null address, the null pointer dereference
bug will happen.

This patch uses a stack variable to replace the kmalloc().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db; https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85; https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b
CVE: CVE-2024-27038
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: Fix clk_core_get NULL dereference

It is possible for clk_core_get to dereference a NULL in the following
sequence:

clk_core_get()
    of_clk_get_hw_from_clkspec()
        __of_clk_get_hw_from_provider()
            __clk_get_hw()

__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
hw->core.

Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
caught the NULL.

Reading the description of this function it talks about returning NULL but
that cannot be so at the moment.

Update the function to check for hw before dereferencing it and return NULL
if hw is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2; https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185; https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51
CVE: CVE-2024-27039
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: hisilicon: hi3559a: Fix an erroneous devm_kfree()

'p_clk' is an array allocated just before the for loop for all clk that
need to be registered.
It is incremented at each loop iteration.

If a clk_register() call fails, 'p_clk' may point to something different
from what should be freed.

The best we can do, is to avoid this wrong release of memory.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2cc572e0085ebd4b662b74a0f43222bc00df9a00; https://git.kernel.org/stable/c/3f8445f1c746fda180a7f75372ed06b24e9cefe2; https://git.kernel.org/stable/c/64c6a38136b74a2f18c[PII_REDACTED]5edd9fbc379
CVE: CVE-2024-27040
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()'

In the first if statement, we're checking if 'replay' is NULL. But in
the second if statement, we're not checking if 'replay' is NULL again
before calling replay->funcs->replay_set_power_opt().

if (replay == NULL && force_static)
    return false;

...

if (link->replay_settings.replay_feature_enabled &&
    replay->funcs->replay_set_power_opt) {
	replay->funcs->replay_set_power_opt(replay, *power_opts, panel_inst);
	link->replay_settings.replay_power_opt_active = *power_opts;
}

If 'replay' is NULL, this will cause a null pointer dereference.

Fixes the below found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:895 edp_set_replay_allow_active() error: we previously assumed 'replay' could be null (see line 887)
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/d0e94f4807ff0df66cf447d6b4bbb8ac830e99c3; https://git.kernel.org/stable/c/e7cadd5d3a8ffe334d0229ba9eda4290138d56e7; https://git.kernel.org/stable/c/f610c46771ef1047e46d61807aa7c69cd29e63d8
CVE: CVE-2024-27041
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()

Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.

Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in
'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().
Clean up by combining them all under one 'if'.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b; https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c; https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957
CVE: CVE-2024-27042
Published: 2024-05-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27043
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: edia: dvbdev: fix a use-after-free

In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:

budget_register
  |-> dvb_dmxdev_init
        |-> dvb_register_device
  |-> dvb_dmxdev_release
        |-> dvb_unregister_device
              |-> dvb_remove_device
                    |-> dvb_device_put
                          |-> kref_put

When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644; https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e; https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d
CVE: CVE-2024-27044
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'

The 'stream' pointer is used in dcn10_set_output_transfer_func() before
the check if 'stream' is NULL.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7; https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0; https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7
CVE: CVE-2024-27045
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'

Tell snprintf() to store at most 10 bytes in the output buffer
instead of 30.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10
CVSS Score: 7.8 (HIGH)
CWE: CWE-120
References: https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877; https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e[PII_REDACTED]bc05141; https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7
CVE: CVE-2024-27046
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nfp: flower: handle acti_netdevs allocation failure

The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.

This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5; https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d; https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642
CVE: CVE-2024-27047
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: fix phy_get_internal_delay accessing an empty array

The phy_get_internal_delay function could try to access to an empty
array in the case that the driver is calling phy_get_internal_delay
without defining delay_values and rx-internal-delay-ps or
tx-internal-delay-ps is defined to 0 in the device-tree.
This will lead to "unable to handle kernel NULL pointer dereference at
virtual address 0". To avoid this kernel oops, the test should be delay
>= 0. As there is already delay < 0 test just before, the test could
only be size == 0.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad; https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b; https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a
CVE: CVE-2024-27048
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcm80211: handle pmk_op allocation failure

The kzalloc() in brcmf_pmksa_v3_op() will return null if the
physical memory has run out. As a result, if we dereference
the null value, the null pointer dereference bug will happen.

Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails
for pmk_op.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6138a82f3bccfc67ed7ac059493579fc326c02e5; https://git.kernel.org/stable/c/[PII_REDACTED]c13bae2f2ed5ba92870fa935180b0e; https://git.kernel.org/stable/c/b4152222e04cb8afeeca239c90e3fcaf4c553b42
CVE: CVE-2024-27049
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925e: fix use-after-free in free_irq()

From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test
to make sure the shared irq handler should be able to handle the unexpected
event after deregistration. For this case, let's apply MT76_REMOVED flag to
indicate the device was removed and do not run into the resource access
anymore.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/6d9930096e1f13cf6d9aabfbf95d0e05fb04144f; https://git.kernel.org/stable/c/84470b48af03a818039d587478b415cbcb264ff5; https://git.kernel.org/stable/c/a5a5f4413d91f395cb2d89829d376d7393ad48b9
CVE: CVE-2024-27050
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

libbpf: Use OPTS_SET() macro in bpf_xdp_query()

When the feature_flags and xdp_zc_max_segs fields were added to the libbpf
bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.
This causes libbpf to write to those fields unconditionally, which means
that programs compiled against an older version of libbpf (with a smaller
size of the bpf_xdp_query_opts struct) will have its stack corrupted by
libbpf writing out of bounds.

The patch adding the feature_flags field has an early bail out if the
feature_flags field is not part of the opts struct (via the OPTS_HAS)
macro, but the patch adding xdp_zc_max_segs does not. For consistency, this
fix just changes the assignments to both fields to use the OPTS_SET()
macro.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/682ddd62abd4bdcee[PII_REDACTED]e7a2df005fe0d; https://git.kernel.org/stable/c/92a871ab9fa59a74d013bc04f321026a057618e7; https://git.kernel.org/stable/c/cd3be9843247edb8fc6fcd8d8237cbce2bc19f5e
CVE: CVE-2024-27051
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5; https://git.kernel.org/stable/c/9127599c075caff[PII_REDACTED]17018a010dd01db; https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035
CVE: CVE-2024-27052
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work

The workqueue might still be running, when the driver is stopped. To
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().
CVSS Score: 7.4 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361; https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e; https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e
CVE: CVE-2024-27053
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: fix RCU usage in connect path

With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:

=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x48
 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
 wilc_parse_join_bss_param from connect+0x2c4/0x648
 connect from cfg80211_connect+0x30c/0xb74
 cfg80211_connect from nl80211_connect+0x860/0xa94
 nl80211_connect from genl_rcv_msg+0x3fc/0x59c
 genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
 netlink_rcv_skb from genl_rcv+0x2c/0x3c
 genl_rcv from netlink_unicast+0x3b0/0x550
 netlink_unicast from netlink_sendmsg+0x368/0x688
 netlink_sendmsg from ____sys_sendmsg+0x190/0x430
 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158
 ___sys_sendmsg from sys_sendmsg+0xe8/0x150
 sys_sendmsg from ret_fast_syscall+0x0/0x1c

This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-476
References: https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f; https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce; https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de
CVE: CVE-2024-27054
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: fix double module refcount decrement

Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount.  Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9fe0562179d8fa960afca0eaed6d4ba4122a3cc6; https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a; https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06