deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26712
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/kasan: Fix addr error caused by page alignment

In kasan_init_region, when k_start is not page aligned, at the begin of
for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
because the memory address space from va to block is not alloced by
memblock_alloc, which will not be reserved by memblock_reserve later, it
will be used by other places.

As a result, memory overwriting occurs.

for example:
int __init __weak kasan_init_region(void *start, size_t size)
{
[...]
	/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
	block = memblock_alloc(k_end - k_start, PAGE_SIZE);
	[...]
	for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
		/* at the begin of for loop
		 * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
		 * va(dcd96c00) is less than block(dcd97000), va is invalid
		 */
		void *va = block + k_cur - k_start;
		[...]
	}
[...]
}

Therefore, page alignment is performed on k_start before
memblock_alloc() to ensure the validity of the VA address.
CVSS Score: 4.4 (MEDIUM)
References: https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe; https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058; https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882
CVE: CVE-2024-26713
Published: 2024-04-03
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26714
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

interconnect: qcom: sc8180x: Mark CO0 BCM keepalive

The CO0 BCM needs to be up at all times, otherwise some hardware (like
the UFS controller) loses its connection to the rest of the SoC,
resulting in a hang of the platform, accompanied by a spectacular
logspam.

Mark it as keepalive to prevent such cases.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7; https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0; https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0
CVE: CVE-2024-26715
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend

In current scenario if Plug-out and Plug-In performed continuously
there could be a chance while checking for dwc->gadget_driver in
dwc3_gadget_suspend, a NULL pointer dereference may occur.

Call Stack:

	CPU1:                           CPU2:
	gadget_unbind_driver            dwc3_suspend_common
	dwc3_gadget_stop                dwc3_gadget_suspend
                                        dwc3_disconnect_gadget

CPU1 basically clears the variable and CPU2 checks the variable.
Consider CPU1 is running and right before gadget_driver is cleared
and in parallel CPU2 executes dwc3_gadget_suspend where it finds
dwc->gadget_driver which is not NULL and resumes execution and then
CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where
it checks dwc->gadget_driver is already NULL because of which the
NULL pointer deference occur.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182; https://git.kernel.org/stable/c/57e2e42ccd3cd[PII_REDACTED]715ed032f44536751; https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316
CVE: CVE-2024-26716
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: core: Prevent null pointer dereference in update_port_device_state

Currently, the function update_port_device_state gets the usb_hub from
udev->parent by calling usb_hub_to_struct_hub.
However, in case the actconfig or the maxchild is 0, the usb_hub would
be NULL and upon further accessing to get port_dev would result in null
pointer dereference.

Fix this by introducing an if check after the usb_hub is populated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/12783c0b9e2c7915a50d5ec829630ff2da50472c; https://git.kernel.org/stable/c/465b545d1d7ef282192ddd4439b08279bdb13f6f; https://git.kernel.org/stable/c/ed85777c640cf9e6920bb1b60ed8cd48e1f4d873
CVE: CVE-2024-26717
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: i2c-hid-of: fix NULL-deref on failed power up

A while back the I2C HID implementation was split in an ACPI and OF
part, but the new OF driver never initialises the client pointer which
is dereferenced on power-up failures.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f; https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776; https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783
CVE: CVE-2024-26718
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

dm-crypt, dm-verity: disable tasklets

Tasklets have an inherent problem with memory corruption. The function
tasklet_action_common calls tasklet_trylock, then it calls the tasklet
callback and then it calls tasklet_unlock. If the tasklet callback frees
the structure that contains the tasklet or if it calls some code that may
free it, tasklet_unlock will write into free memory.

The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but
it is not a sufficient fix and the data corruption can still happen [1].
There is no fix for dm-verity and dm-verity will write into free memory
with every tasklet-processed bio.

There will be atomic workqueues implemented in the kernel 6.9 [2]. They
will have better interface and they will not suffer from the memory
corruption problem.

But we need something that stops the memory corruption now and that can be
backported to the stable kernels. So, I'm proposing this commit that
disables tasklets in both dm-crypt and dm-verity. This commit doesn't
remove the tasklet support, because the tasklet code will be reused when
atomic workqueues will be implemented.

[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/
[2] https://lore.kernel.org/lkml/[PII_REDACTED][PII_REDACTED]-1-tj@kernel.org/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189; https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257; https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94
CVE: CVE-2024-26719
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

nouveau: offload fence uevents work to workqueue

This should break the deadlock between the fctx lock and the irq lock.

This offloads the processing off the work from the irq into a workqueue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/39126abc5e[PII_REDACTED]2f03b66627d7cd1422f0; https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9; https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906
CVE: CVE-2024-26720
Published: 2024-04-03
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26721
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address

Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS
register") defines a new macro to calculate the DSC PPS register
addresses with PPS number as an input. This macro correctly calculates
the addresses till PPS 11 since the addresses increment by 4. So in that
case the following macro works correctly to give correct register
address:

_MMIO(_DSCA_PPS_0 + (pps) * 4)

However after PPS 11, the register address for PPS 12 increments by 12
because of RC Buffer memory allocation in between. Because of this
discontinuity in the address space, the macro calculates wrong addresses
for PPS 12 - 16 resulting into incorrect DSC PPS parameter value
read/writes causing DSC corruption.

This fixes it by correcting this macro to add the offset of 12 for PPS
>=12.

v3: Add correct paranthesis for pps argument (Jani Nikula)

(cherry picked from commit 6074be620c31dc2ae11af96a1a5ea95580976fb5)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-131
References: https://git.kernel.org/stable/c/962ac2dce56bb3aad1f82a4bbe3ada57a020287c; https://git.kernel.org/stable/c/ff5999fb03f467e1e7159f0ddb199c787f7512b9; https://git.kernel.org/stable/c/962ac2dce56bb3aad1f82a4bbe3ada57a020287c
CVE: CVE-2024-26722
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()

There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex
is left locked forever. That may lead to deadlock
when rt5645_jack_detect_work() is called for the second time.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/050ad2ca0ac169dd9e552075d2c6af1bbb46534c; https://git.kernel.org/stable/c/1f0d7792e9023e8658e901b7b76a555f6aa052ec; https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293c7454b2
CVE: CVE-2024-26723
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

lan966x: Fix crash when adding interface under a lag

There is a crash when adding one of the lan966x interfaces under a lag
interface. The issue can be reproduced like this:
ip link add name bond0 type bond miimon 100 mode balance-xor
ip link set dev eth0 master bond0

The reason is because when adding a interface under the lag it would go
through all the ports and try to figure out which other ports are under
that lag interface. And the issue is that lan966x can have ports that are
NULL pointer as they are not probed. So then iterating over these ports
it would just crash as they are NULL pointers.
The fix consists in actually checking for NULL pointers before accessing
something from the ports. Like we do in other places.
CVSS Score: 7.8 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e; https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1; https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df[PII_REDACTED]c
CVE: CVE-2024-26726
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't drop extent_map for free space inode on write error

While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.

assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
 <TASK>
 extent_write_cache_pages+0x2ac/0x8f0
 extent_writepages+0x87/0x110
 do_writepages+0xd5/0x1f0
 filemap_fdatawrite_wbc+0x63/0x90
 __filemap_fdatawrite_range+0x5c/0x80
 btrfs_fdatawrite_range+0x1f/0x50
 btrfs_write_out_cache+0x507/0x560
 btrfs_write_dirty_block_groups+0x32a/0x420
 commit_cowonly_roots+0x21b/0x290
 btrfs_commit_transaction+0x813/0x1360
 btrfs_sync_file+0x51a/0x640
 __x64_sys_fdatasync+0x52/0x90
 do_syscall_64+0x9c/0x190
 entry_SYSCALL_64_after_hwframe+0x6e/0x76

This happens because we fail to write out the free space cache in one
instance, come back around and attempt to write it again.  However on
the second pass through we go to call btrfs_get_extent() on the inode to
get the extent mapping.  Because this is a new block group, and with the
free space inode we always search the commit root to avoid deadlocking
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
requested range.

This happens because the first time we try to write the space cache out
we hit an error, and on an error we drop the extent mapping.  This is
normal for normal files, but the free space cache inode is special.  We
always expect the extent map to be correct.  Thus the second time
through we end up with a bogus extent map.

Since we're deprecating this feature, the most straightforward way to
fix this is to simply skip dropping the extent map range for this failed
range.

I shortened the test by using error injection to stress the area to make
it easier to reproduce.  With this patch in place we no longer panic
with my error injection test.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555; https://git.kernel.org/stable/c/143842584c1237ebc248b2547c29d16bbe400a92; https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade
CVE: CVE-2024-26727
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not ASSERT() if the newly created subvolume already got read

[BUG]
There is a syzbot crash, triggered by the ASSERT() during subvolume
creation:

 assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
 ------------[ cut here ]------------
 kernel BUG at fs/btrfs/disk-io.c:1319!
 invalid opcode: 0000 [#1] PREEMPT SMP KASAN
 RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
  <TASK>
  btrfs_get_new_fs_root+0xd3/0xf0
  create_subvol+0xd02/0x1650
  btrfs_mksubvol+0xe95/0x12b0
  __btrfs_ioctl_snap_create+0x2f9/0x4f0
  btrfs_ioctl_snap_create+0x16b/0x200
  btrfs_ioctl+0x35f0/0x5cf0
  __x64_sys_ioctl+0x19d/0x210
  do_syscall_64+0x3f/0xe0
  entry_SYSCALL_64_after_hwframe+0x63/0x6b
 ---[ end trace [PII_REDACTED] ]---

[CAUSE]
During create_subvol(), after inserting root item for the newly created
subvolume, we would trigger btrfs_get_new_fs_root() to get the
btrfs_root of that subvolume.

The idea here is, we have preallocated an anonymous device number for
the subvolume, thus we can assign it to the new subvolume.

But there is really nothing preventing things like backref walk to read
the new subvolume.
If that happens before we call btrfs_get_new_fs_root(), the subvolume
would be read out, with a new anonymous device number assigned already.

In that case, we would trigger ASSERT(), as we really expect no one to
read out that subvolume (which is not yet accessible from the fs).
But things like backref walk is still possible to trigger the read on
the subvolume.

Thus our assumption on the ASSERT() is not correct in the first place.

[FIX]
Fix it by removing the ASSERT(), and just free the @anon_dev, reset it
to 0, and continue.

If the subvolume tree is read out by something else, it should have
already get a new anon_dev assigned thus we only need to free the
preallocated one.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f; https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468; https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d
CVE: CVE-2024-28275
Published: 2024-04-03
Description: Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) was discovered to transmit sensitive information in cleartext. This vulnerability allows attackers to intercept and access sensitive information, including users' credentials and password change requests.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-319
References: https://paste.sr.ht/~edaigle/0b4a037fbd3166c8c72fee18efaa7decaf75b0ab; https://paste.sr.ht/~edaigle/c9637d682b65e6501efb1324bba7787a2f775ff4; https://paste.sr.ht/~edaigle/0b4a037fbd3166c8c72fee18efaa7decaf75b0ab
CVE: CVE-2023-44039
Published: 2024-04-03
Description: In VeridiumID before 3.5.0, the WebAuthn API allows an internal unauthenticated attacker (who can pass enrollment verifications and is allowed to enroll a FIDO key) to register their FIDO authenticator to a victim’s account and consequently take over the account.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-287
References: https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement; https://veridiumid.com/veridium-id-authentication-platform/; https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement
CVE: CVE-2024-27673
Published: 2024-04-03
Description: Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE: CVE-2024-31392
Published: 2024-04-03
Description: If an insecure element was added to a page after a delay, Firefox would not replace the secure icon with a mixed content security status This vulnerability affects Firefox for iOS < 124.
CVSS Score: 7.5 (HIGH)
References: https://bugzilla.mozilla.org/show_bug.cgi?id=1875925; https://www.mozilla.org/security/advisories/mfsa2024-17/; https://bugzilla.mozilla.org/show_bug.cgi?id=1875925
CVE: CVE-2024-31393
Published: 2024-04-03
Description: Dragging Javascript URLs to the address bar could cause them to be loaded, bypassing restrictions and security protections This vulnerability affects Firefox for iOS < 124.
CVSS Score: 4.3 (MEDIUM)
References: https://bugzilla.mozilla.org/show_bug.cgi?id=1879739; https://www.mozilla.org/security/advisories/mfsa2024-17/; https://bugzilla.mozilla.org/show_bug.cgi?id=1879739
CVE: CVE-2023-35812
Published: 2024-04-03
Description: An issue was discovered in the Amazon Linux packages of OpenSSH 7.4 for Amazon Linux 1 and 2, because of an incomplete fix for CVE-2019-6111 within these specific packages. The fix had only covered cases where an absolute path is passed to scp. When a relative path is used, there is no verification that the name of a file received by the client matches the file requested. Fixed packages are available with numbers 7.4p1-22.78.amzn1 and 7.4p1-22.amzn2.0.2.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-22
References: https://alas.aws.amazon.com/cve/html/CVE-2023-35812.html; https://alas.aws.amazon.com/cve/html/CVE-2023-35812.html
CVE: CVE-2023-44038
Published: 2024-04-03
Description: In VeridiumID before 3.5.0, the identity provider page allows an unauthenticated attacker to discover information about registered users via an LDAP injection attack.
CVSS Score: 6.5 (MEDIUM)
References: https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement; https://veridiumid.com/veridium-id-authentication-platform/; https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement
CVE: CVE-2023-44040
Published: 2024-04-03
Description: In VeridiumID before 3.5.0, the identity provider page is susceptible to a cross-site scripting (XSS) vulnerability that can be exploited by an internal unauthenticated attacker for JavaScript execution in the context of the user trying to authenticate.
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-79
References: https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement; https://veridiumid.com/veridium-id-authentication-platform/; https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement
CVE: CVE-2023-45552
Published: 2024-04-03
Description: In VeridiumID before 3.5.0, a stored cross-site scripting (XSS) vulnerability has been discovered in the admin portal that allows an authenticated attacker to take over all accounts by sending malicious input via the self-service portal.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement; https://veridiumid.com/veridium-id-authentication-platform/; https://docs.veridiumid.com/docs/v3.5/security-advisory#id-%28v3.52%29SecurityAdvisory-Acknowledgement
CVE: CVE-2023-52640
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix oob in ntfs_listxattr

The length of name cannot exceed the space occupied by ea.
CVSS Score: 7.1 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c; https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23; https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb
CVE: CVE-2023-52641
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()

It is preferable to exit through the out: label because
internal debugging functions are located there.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc; https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd; https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c
CVE: CVE-2024-1180
Published: 2024-04-03
Description: TP-Link Omada ER605 Access Control Command Injection Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of TP-Link Omada ER605. Authentication is required to exploit this vulnerability.

The specific issue exists within the handling of the name field in the access control user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-22227.
CVSS Score: 8.0 (HIGH)
CWE: CWE-78
References: https://www.zerodayinitiative.com/advisories/ZDI-24-086/; https://www.zerodayinitiative.com/advisories/ZDI-24-086/
CVE: CVE-2024-20281
Published: 2024-04-03
Description: A vulnerability in the web-based management interface of Cisco Nexus Dashboard and Cisco Nexus Dashboard hosted services could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack on an affected system.
 This vulnerability is due to insufficient CSRF protections for the web-based management interface on an affected system. An attacker could exploit this vulnerability by persuading a user to click a malicious link. A successful exploit could allow the attacker to perform arbitrary actions with the privilege level of the affected user. If the affected user has administrative privileges, these actions could include modifying the system configuration and creating new privileged accounts.
 Note: There are internal security mechanisms in place that limit the scope of this exploit, reducing the Security Impact Rating of this vulnerability.
CVSS Score: 7.5 (HIGH)
CWE: CWE-352, CWE-352
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndfccsrf-TEmZEfJ9; https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndfccsrf-TEmZEfJ9
CVE: CVE-2024-20282
Published: 2024-04-03
Description: A vulnerability in Cisco Nexus Dashboard could allow an authenticated, local attacker with valid rescue-user credentials to elevate privileges to root on an affected device.
 This vulnerability is due to insufficient protections for a sensitive access token. An attacker could exploit this vulnerability by using this token to access resources within the device infrastructure. A successful exploit could allow an attacker to gain root access to the filesystem or hosted containers on an affected device.
CVSS Score: 6.0 (MEDIUM)
CWE: CWE-269, CWE-522
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndru-pesc-kZ2PQLZH; https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndru-pesc-kZ2PQLZH