deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-52587
Published: 2024-11-18
Description: StepSecurity's Harden-Runner provides network egress filtering and runtime security for GitHub-hosted and self-hosted runners. Versions of step-security/harden-runner prior to v2.10.2 contain multiple command injection weaknesses via environment variables that could potentially be exploited under specific conditions. However, due to the current execution order of pre-steps in GitHub Actions and the placement of harden-runner as the first step in a job, the likelihood of exploitation is low as the Harden-Runner action reads the environment variable during the pre-step stage. There are no known exploits at this time. Version 2.10.2 contains a patch.
CVSS Score: 8.8 (HIGH)
CWE: CWE-78
References: https://github.com/step-security/harden-runner/blob/951b48540b429070694bc8abd82fd6901eb123ca/src/arc-runner.ts#L40-L44; https://github.com/step-security/harden-runner/blob/951b48540b429070694bc8abd82fd6901eb123ca/src/arc-runner.ts#L53; https://github.com/step-security/harden-runner/blob/951b48540b429070694bc8abd82fd6901eb123ca/src/arc-runner.ts#L57
CVE: CVE-2024-33231
Published: 2024-11-18
Description: Cross Site Scripting vulnerability in Ferozo Email version 1.1 allows a local attacker to execute arbitrary code via a crafted payload to the PDF preview component.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://github.com/fdzdev/CVE-2024-33231
CVE: CVE-2024-51939
Published: 2024-11-18
Description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Santhosh veer Stylish Internal Links stylish-internal-links allows DOM-Based XSS.This issue affects Stylish Internal Links: from n/a through <= 1.9.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://patchstack.com/database/Wordpress/Plugin/stylish-internal-links/vulnerability/wordpress-stylish-internal-links-plugin-1-9-cross-site-scripting-xss-vulnerability?_s_id=cve
CVE: CVE-2024-51940
Published: 2024-11-18
Description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Sohelwpexpert WP Responsive Video my-wp-responsive-video allows DOM-Based XSS.This issue affects WP Responsive Video: from n/a through <= 1.0.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://patchstack.com/database/Wordpress/Plugin/my-wp-responsive-video/vulnerability/wordpress-wp-responsive-video-plugin-1-0-cross-site-scripting-xss-vulnerability?_s_id=cve
CVE: CVE-2024-52339
Published: 2024-11-18
Description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Maximilian Ruthe Mage Front End Forms mage-forms allows Stored XSS.This issue affects Mage Front End Forms: from n/a through <= 1.1.4.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://patchstack.com/database/Wordpress/Plugin/mage-forms/vulnerability/wordpress-mage-front-end-forms-plugin-1-1-4-cross-site-scripting-xss-vulnerability?_s_id=cve
CVE: CVE-2024-52340
Published: 2024-11-18
Description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in MartyThornley Photographer Connections photographer-connections allows Stored XSS.This issue affects Photographer Connections: from n/a through <= 1.3.1.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://patchstack.com/database/Wordpress/Plugin/photographer-connections/vulnerability/wordpress-photographer-connections-plugin-1-3-1-cross-site-scripting-xss-vulnerability?_s_id=cve
CVE: CVE-2023-52921
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix possible UAF in amdgpu_cs_pass1()

Since the gang_size check is outside of chunk parsing
loop, we need to reset i before we free the chunk data.

Suggested by Ye Zhang (@VAR10CK) of Baidu Security.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/90e065677e0362a777b9db97ea21d43a39211399; https://git.kernel.org/stable/c/e08e9dd09809b16f8f8cee8c466841b33d24ed96
CVE: CVE-2024-50264
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in
vsk->trans, potentially leading to a Use-After-Free condition.  This
issue is resolved by initializing vsk->trans to NULL.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://a13xp0p0v.github.io/2025/09/02/kernel-hack-drill-and-CVE-2024-50264.html; https://git.kernel.org/stable/c/2a6a4e69f255b7aed17f93995691ab4f0d3c2203; https://git.kernel.org/stable/c/44d29897eafd0e1196453d3003a4d5e0b968eeab
CVE: CVE-2024-50265
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():

[   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry
[   57.321727] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[...]
[   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[   57.331328] Call Trace:
[   57.331477]  <TASK>
[...]
[   57.333511]  ? do_user_addr_fault+0x3e5/0x740
[   57.333778]  ? exc_page_fault+0x70/0x170
[   57.334016]  ? asm_exc_page_fault+0x2b/0x30
[   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0
[   57.335164]  ocfs2_xa_set+0x704/0xcf0
[   57.335381]  ? _raw_spin_unlock+0x1a/0x40
[   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20
[   57.335915]  ? trace_preempt_on+0x1e/0x70
[   57.336153]  ? start_this_handle+0x16c/0x500
[   57.336410]  ? preempt_count_sub+0x50/0x80
[   57.336656]  ? _raw_read_unlock+0x20/0x40
[   57.336906]  ? start_this_handle+0x16c/0x500
[   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0
[   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0
[   57.337706]  ? ocfs2_start_trans+0x13d/0x290
[   57.337971]  ocfs2_xattr_set+0xb13/0xfb0
[   57.338207]  ? dput+0x46/0x1c0
[   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30
[   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30
[   57.338948]  __vfs_removexattr+0x92/0xc0
[   57.339182]  __vfs_removexattr_locked+0xd5/0x190
[   57.339456]  ? preempt_count_sub+0x50/0x80
[   57.339705]  vfs_removexattr+0x5f/0x100
[...]

Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->
ocfs2_xa_value_truncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0b63c0e01fba40e3992bc627272ec7b618ccaef7; https://git.kernel.org/stable/c/168a9b8303fcb0317db4c06b23ce1c0ce2af4e10; https://git.kernel.org/stable/c/2b5369528ee63c[PII_REDACTED]8a05b5e664c87386
CVE: CVE-2024-50266
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs

A recent change in the venus driver results in a stuck clock on the
Lenovo ThinkPad X13s, for example, when streaming video in firefox:

	video_cc_mvs0_clk status stuck at 'off'
	WARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c
	...
	Call trace:
	 clk_branch_wait+0x144/0x15c
	 clk_branch2_enable+0x30/0x40
	 clk_core_enable+0xd8/0x29c
	 clk_enable+0x2c/0x4c
	 vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core]
	 coreid_power_v4+0x464/0x628 [venus_core]
	 vdec_start_streaming+0xc4/0x510 [venus_dec]
	 vb2_start_streaming+0x6c/0x180 [videobuf2_common]
	 vb2_core_streamon+0x120/0x1dc [videobuf2_common]
	 vb2_streamon+0x1c/0x6c [videobuf2_v4l2]
	 v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem]
	 v4l_streamon+0x24/0x30 [videodev]

using the out-of-tree sm8350/sc8280xp venus support. [1]

Update also the sm8350/sc8280xp GDSC definitions so that the hw control
mode can be changed at runtime as the venus driver now requires.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/d055f6f2bdfb8b9c9bc071f748c16bd3afb2db0f; https://git.kernel.org/stable/c/f903663a8dcd6e1656e52856afbf706cc14cbe6d
CVE: CVE-2024-50267
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: serial: io_edgeport: fix use after free in debug printk

The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb)
is a use after free of the "urb" pointer.  Store the "dev" pointer at the
start of the function to avoid this issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/13d6ff3ca76056d06a9d88300be2a293442ff595; https://git.kernel.org/stable/c/275258c30bbda29467216e96fb655b16bcc9992b; https://git.kernel.org/stable/c/314bdf446053e123f37543aa535197ee75f8aa97
CVE: CVE-2024-50268
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()

The "*cmd" variable can be controlled by the user via debugfs.  That means
"new_cam" can be as high as 255 while the size of the uc->updated[] array
is UCSI_MAX_ALTMODES (30).

The call tree is:
ucsi_cmd() // val comes from simple_attr_write_xsigned()
-> ucsi_send_command()
   -> ucsi_send_command_common()
      -> ucsi_run_command() // calls ucsi->ops->sync_control()
         -> ucsi_ccg_sync_control()
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/3a2ba841659a0f[PII_REDACTED]dea75d8d5209616; https://git.kernel.org/stable/c/604314ecd[PII_REDACTED]80dc955caea2d036eab5f; https://git.kernel.org/stable/c/69e19774f15e12dda6c6c58001d059e30895009b
CVE: CVE-2024-50269
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: musb: sunxi: Fix accessing an released usb phy

Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on
exit") will cause that usb phy @glue->xceiv is accessed after released.

1) register platform driver @sunxi_musb_driver
// get the usb phy @glue->xceiv
sunxi_musb_probe() -> devm_usb_get_phy().

2) register and unregister platform driver @musb_driver
musb_probe() -> sunxi_musb_init()
use the phy here
//the phy is released here
musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()

3) register @musb_driver again
musb_probe() -> sunxi_musb_init()
use the phy here but the phy has been released at 2).
...

Fixed by reverting the commit, namely, removing devm_usb_put_phy()
from sunxi_musb_exit().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/498dbd9aea205db9da674994b74c7bf8e18448bd; https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1; https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522bf377dd9
CVE: CVE-2024-50270
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/core: avoid overflow in damon_feed_loop_next_input()

damon_feed_loop_next_input() is inefficient and fragile to overflows. 
Specifically, 'score_goal_diff_bp' calculation can overflow when 'score'
is high.  The calculation is actually unnecessary at all because 'goal' is
a constant of value 10,000.  Calculation of 'compensation' is again
fragile to overflow.  Final calculation of return value for under-achiving
case is again fragile to overflow when the current score is
under-achieving the target.

Add two corner cases handling at the beginning of the function to make the
body easier to read, and rewrite the body of the function to avoid
overflows and the unnecessary bp value calcuation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/2d339a1f0f16ff5dea58e612ff336f0be0d041e9; https://git.kernel.org/stable/c/4401e9d10ab0281a520b9f8c220f30f60b5c248f
CVE: CVE-2024-50271
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

signal: restore the override_rlimit logic

Prior to commit d[PII_REDACTED]4 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals.  However now it's enforced unconditionally, even if
override_rlimit is set.  This behavior change caused production issues.  

For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo. 
This prevents the process from correctly identifying the fault address and
handling the error.  From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'.  This can lead to unpredictable behavior and
crashes, as we observed with java applications.

Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set.  This effectively
restores the old behavior.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770, CWE-770
References: https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1; https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40; https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7
CVE: CVE-2024-50272
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

filemap: Fix bounds checking in filemap_read()

If the caller supplies an iocb->ki_pos value that is close to the
filesystem upper limit, and an iterator with a count that causes us to
overflow that limit, then filemap_read() enters an infinite loop.

This behaviour was discovered when testing xfstests generic/525 with the
"localio" optimisation for loopback NFS mounts.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/26530b757c81f1389fb33ae[PII_REDACTED]933161b; https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826; https://git.kernel.org/stable/c/6cc52df69e8464811f9f6fc12f7aaa78451eb0b8
CVE: CVE-2024-50273
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: reinitialize delayed ref list after deleting it from the list

At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.

If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.

So fix this by deleting from the list with list_del_init() instead.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6; https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d; https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a19357a92
CVE: CVE-2024-50274
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: avoid vport access in idpf_get_link_ksettings

When the device control plane is removed or the platform
running device control plane is rebooted, a reset is detected
on the driver. On driver reset, it releases the resources and
waits for the reset to complete. If the reset fails, it takes
the error path and releases the vport lock. At this time if the
monitoring tools tries to access link settings, it call traces
for accessing released vport pointer.

To avoid it, move link_speed_mbps to netdev_priv structure
which removes the dependency on vport pointer and the vport lock
in idpf_get_link_ksettings. Also use netif_carrier_ok()
to check the link status and adjust the offsetof to use link_up
instead of link_speed_mbps.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/81d2fb4c7c18a3b36ba3e00b9d5b753107472d75; https://git.kernel.org/stable/c/fa4d906ad0fb63a980a1d586a061c78ea1a345ba
CVE: CVE-2024-50275
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/sve: Discard stale CPU state when handling SVE traps

The logic for handling SVE traps manipulates saved FPSIMD/SVE state
incorrectly, and a race with preemption can result in a task having
TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SVE traps enabled). This has been observed to result
in warnings from do_sve_acc() where SVE traps are not expected while
TIF_SVE is set:

|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */

Warnings of this form have been reported intermittently, e.g.

  https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/
  https://lore.kernel.org/linux-arm-kernel/[PII_REDACTED]00511e9a060ce5a45c@google.com/

The race can occur when the SVE trap handler is preempted before and
after manipulating the saved FPSIMD/SVE state, starting and ending on
the same CPU, e.g.

| void do_sve_acc(unsigned long esr, struct pt_regs *regs)
| {
|         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
|         // task->fpsimd_cpu is 0.
|         // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
|         ...
|
|         // Preempted; migrated from CPU 0 to CPU 1.
|         // TIF_FOREIGN_FPSTATE is set.
|
|         get_cpu_fpsimd_context();
|
|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */
|
|         sve_init_regs() {
|                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
|                         ...
|                 } else {
|                         fpsimd_to_sve(current);
|                         current->thread.fp_type = FP_STATE_SVE;
|                 }
|         }
|
|         put_cpu_fpsimd_context();
|
|         // Preempted; migrated from CPU 1 to CPU 0.
|         // task->fpsimd_cpu is still 0
|         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
|         // - Stale HW state is reused (with SVE traps enabled)
|         // - TIF_FOREIGN_FPSTATE is cleared
|         // - A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.
CVSS Score: 7.0 (HIGH)
References: https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7; https://git.kernel.org/stable/c/51d3d80a6dc314982a9a0aeb[PII_REDACTED]a1aa15; https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a[PII_REDACTED]c0483d18
CVE: CVE-2024-50276
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: vertexcom: mse102x: Fix possible double free of TX skb

The scope of the TX skb is wider than just mse102x_tx_frame_spi(),
so in case the TX skb room needs to be expanded, we should free the
the temporary skb instead of the original skb. Otherwise the original
TX skb pointer would be freed again in mse102x_tx_work(), which leads
to crashes:

  Internal error: Oops: [PII_REDACTED] [#2] PREEMPT SMP
  CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G      D            6.6.23
  Hardware name: chargebyte Charge SOM DC-ONE (DT)
  Workqueue: events mse102x_tx_work [mse102x]
  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : skb_release_data+0xb8/0x1d8
  lr : skb_release_data+0x1ac/0x1d8
  sp : ffff8000819a3cc0
  x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0
  x26: ffff000005386c00 x25: [PII_REDACTED] x24: 00000000ffffffff
  x23: [PII_REDACTED] x22: [PII_REDACTED] x21: ffff0000057f2e50
  x20: [PII_REDACTED] x19: [PII_REDACTED] x18: ffff00003fdacfcc
  x17: e69ad452d0c49def x16: 84a005feff870102 x15: [PII_REDACTED]
  x14:[PII_REDACTED]00024a x13: [PII_REDACTED] x12: [PII_REDACTED]
  x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : ffff00003fd913e8
  x8 : fffffc00001bc008
  x7 : [PII_REDACTED] x6 : [PII_REDACTED]
  x5 : ffff00003fd91340 x4 : [PII_REDACTED] x3 : [PII_REDACTED]
  x2 : 00000000fffffffe x1 : [PII_REDACTED] x0 : [PII_REDACTED]
  Call trace:
   skb_release_data+0xb8/0x1d8
   kfree_skb_reason+0x48/0xb0
   mse102x_tx_work+0x164/0x35c [mse102x]
   process_one_work+0x138/0x260
   worker_thread+0x32c/0x438
   kthread+0x118/0x11c
   ret_from_fork+0x10/0x20
  Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/1325e838089da25217f4b403318a270fcdf88f34; https://git.kernel.org/stable/c/1f26339b2ed63d1e8e18a18674fb73a392f3660e; https://git.kernel.org/stable/c/2cf0e77f5a0aa1ff336aa71743eda55c73902187
CVE: CVE-2024-50277
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

dm: fix a crash if blk_alloc_disk fails

If blk_alloc_disk fails, the variable md->disk is set to an error value.
cleanup_mapped_device will see that md->disk is non-NULL and it will
attempt to access it, causing a crash on this statement
"md->disk->private_data = NULL;".
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829; https://git.kernel.org/stable/c/fed13a[PII_REDACTED]ba97fc87e71f16e2e197912e