deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-42239
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fail bpf_timer_cancel when callback is being cancelled

Given a schedule:

timer1 cb			timer2 cb

bpf_timer_cancel(timer2);	bpf_timer_cancel(timer1);

Both bpf_timer_cancel calls would wait for the other callback to finish
executing, introducing a lockup.

Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps
track of all in-flight cancellation requests for a given BPF timer.
Whenever cancelling a BPF timer, we must check if we have outstanding
cancellation requests, and if so, we must fail the operation with an
error (-EDEADLK) since cancellation is synchronous and waits for the
callback to finish executing. This implies that we can enter a deadlock
situation involving two or more timer callbacks executing in parallel
and attempting to cancel one another.

Note that we avoid incrementing the cancelling counter for the target
timer (the one being cancelled) if bpf_timer_cancel is not invoked from
a callback, to avoid spurious errors. The whole point of detecting
cur->cancelling and returning -EDEADLK is to not enter a busy wait loop
(which may or may not lead to a lockup). This does not apply in case the
caller is in a non-callback context, the other side can continue to
cancel as it sees fit without running into errors.

Background on prior attempts:

Earlier versions of this patch used a bool 'cancelling' bit and used the
following pattern under timer->lock to publish cancellation status.

lock(t->lock);
t->cancelling = true;
mb();
if (cur->cancelling)
	return -EDEADLK;
unlock(t->lock);
hrtimer_cancel(t->timer);
t->cancelling = false;

The store outside the critical section could overwrite a parallel
requests t->cancelling assignment to true, to ensure the parallely
executing callback observes its cancellation status.

It would be necessary to clear this cancelling bit once hrtimer_cancel
is done, but lack of serialization introduced races. Another option was
explored where bpf_timer_start would clear the bit when (re)starting the
timer under timer->lock. This would ensure serialized access to the
cancelling bit, but may allow it to be cleared before in-flight
hrtimer_cancel has finished executing, such that lockups can occur
again.

Thus, we choose an atomic counter to keep track of all outstanding
cancellation requests and use it to prevent lockups in case callbacks
attempt to cancel each other while executing in parallel.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a; https://git.kernel.org/stable/c/[PII_REDACTED]688ecd5b08ffc08ab3302ce2b5d0f7; https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13
CVE: CVE-2024-42240
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/bhi: Avoid warning in #DB handler due to BHI mitigation

When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
(exc_debug_kernel()) to issue a warning because single-step is used outside the
entry_SYSENTER_compat() function.

To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
after making sure the TF flag is cleared.

The problem can be reproduced with the following sequence:

  $ cat sysenter_step.c
  int main()
  { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }

  $ gcc -o sysenter_step sysenter_step.c

  $ ./sysenter_step
  Segmentation fault (core dumped)

The program is expected to crash, and the #DB handler will issue a warning.

Kernel log:

  WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
  ...
  RIP: 0010:exc_debug_kernel+0xd2/0x160
  ...
  Call Trace:
  <#DB>
   ? show_regs+0x68/0x80
   ? __warn+0x8c/0x140
   ? exc_debug_kernel+0xd2/0x160
   ? report_bug+0x175/0x1a0
   ? handle_bug+0x44/0x90
   ? exc_invalid_op+0x1c/0x70
   ? asm_exc_invalid_op+0x1f/0x30
   ? exc_debug_kernel+0xd2/0x160
   exc_debug+0x43/0x50
   asm_exc_debug+0x1e/0x40
  RIP: 0010:clear_bhb_loop+0x0/0xb0
  ...
  </#DB>
  <TASK>
   ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d
  </TASK>

  [ bp: Massage commit message. ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/08518d48e5b744620524f0acd7c26c19bda7f513; https://git.kernel.org/stable/c/a765679defe1dc1b8fa01928a6ad6361e72a1364; https://git.kernel.org/stable/c/ac8b270b61d48fcc61f052097777e3b5e11591e0
CVE: CVE-2024-42241
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/shmem: disable PMD-sized page cache if needed

For shmem files, it's possible that PMD-sized page cache can't be
supported by xarray.  For example, 512MB page cache on ARM64 when the base
page size is 64KB can't be supported by xarray.  It leads to errors as the
following messages indicate when this sort of xarray entry is split.

WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128
Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6   \
nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject        \
nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4  \
ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs  \
libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \
net_failover virtio_console virtio_blk failover dimlib virtio_mmio
CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9
Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : xas_split_alloc+0xf8/0x128
lr : split_huge_page_to_list_to_order+0x1c4/0x720
sp : ffff8000882af5f0
x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768
x26:[PII_REDACTED]000cc0 x25:[PII_REDACTED]00000d x24: ffff00010625b858
x23: ffff8000882af650 x22: ffffffdfc0900000 x21: [PII_REDACTED]
x20: [PII_REDACTED] x19: ffffffdfc0900000 x18: [PII_REDACTED]
x17: [PII_REDACTED] x16: [PII_REDACTED] x15: 52f[PII_REDACTED]000
x14: 0000e[PII_REDACTED]0 x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: 52f[PII_REDACTED]000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c
x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : ffff00010b02ddb0
x5 : ffffbeb96395e378 x4 : [PII_REDACTED] x3 :[PII_REDACTED]000cc0
x2 :[PII_REDACTED]00000d x1 :[PII_REDACTED]00000c x0 : [PII_REDACTED]
Call trace:
 xas_split_alloc+0xf8/0x128
 split_huge_page_to_list_to_order+0x1c4/0x720
 truncate_inode_partial_folio+0xdc/0x160
 shmem_undo_range+0x2bc/0x6a8
 shmem_fallocate+0x134/0x430
 vfs_fallocate+0x124/0x2e8
 ksys_fallocate+0x4c/0xa0
 __arm64_sys_fallocate+0x24/0x38
 invoke_syscall.constprop.0+0x7c/0xd8
 do_el0_svc+0xb4/0xd0
 el0_svc+0x44/0x1d8
 el0t_64_sync_handler+0x134/0x150
 el0t_64_sync+0x17c/0x180

Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger
than MAX_PAGECACHE_ORDER.  As Matthew Wilcox pointed, the page cache in a
shmem file isn't represented by a multi-index entry and doesn't have this
limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm:
Use multi-index entries in the page cache").
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/93893eacb372b0a4a30f7de6609b08c3ba6c4fd9; https://git.kernel.org/stable/c/9fd154ba926b34c833b7bfc4c14ee2e931b3d743; https://git.kernel.org/stable/c/cd25208ca9b0097f8e079d692fc678f36fdbc3f9
CVE: CVE-2024-42242
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE

blk_queue_max_segment_size() ensured:

	if (max_size < PAGE_SIZE)
		max_size = PAGE_SIZE;

whereas:

blk_validate_limits() makes it an error:

	if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
		return -EINVAL;

The change from one to the other, exposed sdhci which was setting maximum
segment size too low in some circumstances.

Fix the maximum segment size when it is too low.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/63d20a94f24fc1cbaf44d0e7c0e0a8077fde0aef; https://git.kernel.org/stable/c/bf78b1accef46efd9b624967cb74ae8d3c215a2b
CVE: CVE-2024-42244
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: serial: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no
alternative is provided in usb serial layer"), USB serial core calls the
generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.

Fix this by implementing dedicated suspend and resume functions for
mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

[ johan: analyse crash and rewrite commit message; set busy flag on
         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1094ed500987e67a9d18b0f95e1812f1cc720856; https://git.kernel.org/stable/c/553e67dec846323b5575e78a776cf594c13f98c4; https://git.kernel.org/stable/c/5ae6a64f18211851c8df6b4221381c438b9a7348
CVE: CVE-2024-42245
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "sched/fair: Make sure to try to detach at least one movable task"

This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.

b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if
all tasks examined to that point were pinned. The goal of the patch was
to make it more likely to be able to detach a task buried in a long list
of pinned tasks. However, this has the unfortunate side effect of
creating an O(n) iteration in detach_tasks(), as we now must fully
iterate every task on a cpu if all or most are pinned. Since this load
balance code is done with rq lock held, and often in softirq context, it
is very easy to trigger hard lockups. We observed such hard lockups with
a user who affined O(10k) threads to a single cpu.

When I discussed this with Vincent he initially suggested that we keep
the limit on the number of tasks to detach, but increase the number of
tasks we can search. However, after some back and forth on the mailing
list, he recommended we instead revert the original patch, as it seems
likely no one was actually getting hit by the original issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b; https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44; https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a
CVE: CVE-2024-42246
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket

When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.

Neil suggested:

  This will propagate -EPERM up into other layers which might not be ready
  to handle it. It might be safer to map EPERM to an error we would be more
  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.

ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean"), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041; https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011; https://git.kernel.org/stable/c/626dfed5fa3bfb41e0dffd796032b555b69f9cde
CVE: CVE-2024-42247
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

wireguard: allowedips: avoid unaligned 64-bit memory accesses

On the parisc platform, the kernel issues kernel warnings because
swap_endian() tries to load a 128-bit IPv6 address from an unaligned
memory location:

 Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
 Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)

Avoid such unaligned memory accesses by instead using the
get_unaligned_be64() helper macro.

[Jason: replace src[8] in original patch with src+8]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/217978a29c6ceca76d3c640bf94bdf50c268d801; https://git.kernel.org/stable/c/2fb34bf76431e831f9863cd59adc0bd1f67b0fbf; https://git.kernel.org/stable/c/6638a203abad35fa636d59ac47bdbc4bc100fd74
CVE: CVE-2024-42248
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: serial: ma35d1: Add a NULL check for of_node

The pdev->dev.of_node can be NULL if the "serial" node is absent.
Add a NULL check to return an error in such cases.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0e0e15ab2d3a094a38525d23c03d78ec7d14a40e; https://git.kernel.org/stable/c/23efa74cfe6eb923abb5b9bc51b2a04879013c67; https://git.kernel.org/stable/c/acd09ac253b5de8fd79fc61a482ee19154914c7a
CVE: CVE-2024-42249
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: don't unoptimize message in spi_async()

Calling spi_maybe_unoptimize_message() in spi_async() is wrong because
the message is likely to be in the queue and not transferred yet. This
can corrupt the message while it is being used by the controller driver.

spi_maybe_unoptimize_message() is already called in the correct place
in spi_finalize_current_message() to balance the call to
spi_maybe_optimize_message() in spi_async().
CVSS Score: 3.3 (LOW)
References: https://git.kernel.org/stable/c/8b9af6d67517ce4a0015928b3cf35bfd2b1bc1c2; https://git.kernel.org/stable/c/c86a918b1bdba78fb155184f8d88dfba1e63335d
CVE: CVE-2024-42250
Published: 2024-08-07
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: add missing lock protection when polling

Add missing lock protection in poll routine when iterating xarray,
otherwise:

Even with RCU read lock held, only the slot of the radix tree is
ensured to be pinned there, while the data structure (e.g. struct
cachefiles_req) stored in the slot has no such guarantee.  The poll
routine will iterate the radix tree and dereference cachefiles_req
accordingly.  Thus RCU read lock is not adequate in this case and
spinlock is needed here.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/6bb6bd3dd6f382dfd36220d4b210a0c77c066651; https://git.kernel.org/stable/c/8eadcab7f3dd809edbe5ae20533ff843dfea3a07; https://git.kernel.org/stable/c/97cfd5e20ddc2e33e16ce369626ce76c9a475fd7
CVE: CVE-2024-7582
Published: 2024-08-07
Description: A vulnerability classified as critical was found in Tenda i22 1.0.0.3(4687). This vulnerability affects the function formApPortalAccessCodeAuth of the file /goform/apPortalAccessCodeAuth. The manipulation of the argument accessCode/data/acceInfo leads to buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 8.8 (HIGH)
CWE: CWE-120, CWE-787
References: https://github.com/BeaCox/IoT_vuln/tree/main/tenda/i22/ApPortalAccessCodeAuth; https://vuldb.com/?ctiid.273862; https://vuldb.com/?id.273862
CVE: CVE-2024-7583
Published: 2024-08-07
Description: A vulnerability, which was classified as critical, has been found in Tenda i22 1.0.0.3(4687). This issue affects the function formApPortalOneKeyAuth of the file /goform/apPortalOneKeyAuth. The manipulation of the argument data leads to buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 8.8 (HIGH)
CWE: CWE-120, CWE-787
References: https://github.com/BeaCox/IoT_vuln/tree/main/tenda/i22/ApPortalOneKeyAuth; https://vuldb.com/?ctiid.273863; https://vuldb.com/?id.273863
CVE: CVE-2024-20443
Published: 2024-08-07
Description: A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to conduct an XSS attack against a user of the interface.

This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, the attacker must have at least a low-privileged account on an affected device.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-xss-V2bm9JCY
CVE: CVE-2024-20450
Published: 2024-08-07
Description: Multiple vulnerabilities in the web-based management interface of Cisco Small Business SPA300 Series IP Phones and Cisco Small Business SPA500 Series IP Phones could allow an unauthenticated, remote attacker to execute arbitrary commands on the underlying operating system with root privileges.

These vulnerabilities exist because incoming HTTP packets are not properly checked for errors, which could result in a buffer overflow. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to overflow an internal buffer and execute arbitrary commands at the root privilege level.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-120, CWE-120
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-spa-http-vulns-RJZmX2Xz
CVE: CVE-2024-20451
Published: 2024-08-07
Description: Multiple vulnerabilities in the web-based management interface of Cisco Small Business SPA300 Series IP Phones and Cisco Small Business SPA500 Series IP Phones could allow an unauthenticated, remote attacker to cause an affected device to reload unexpectedly.

These vulnerabilities exist because HTTP packets are not properly checked for errors. An attacker could exploit this vulnerability by sending a crafted HTTP packet to the remote interface of an affected device. A successful exploit could allow the attacker to cause a DoS condition on the device.
CVSS Score: 7.5 (HIGH)
CWE: CWE-120
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-spa-http-vulns-RJZmX2Xz
CVE: CVE-2024-20454
Published: 2024-08-07
Description: Multiple vulnerabilities in the web-based management interface of Cisco Small Business SPA300 Series IP Phones and Cisco Small Business SPA500 Series IP Phones could allow an unauthenticated, remote attacker to execute arbitrary commands on the underlying operating system with root privileges.

These vulnerabilities exist because incoming HTTP packets are not properly checked for errors, which could result in a buffer overflow. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to overflow an internal buffer and execute arbitrary commands at the root privilege level.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-120, CWE-120
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-spa-http-vulns-RJZmX2Xz
CVE: CVE-2024-20479
Published: 2024-08-07
Description: A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to conduct an XSS attack against a user of the interface.

This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, the attacker must have Admin privileges on an affected device.
CVSS Score: 4.8 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-xss-V2bm9JCY
CVE: CVE-2024-41243
Published: 2024-08-07
Description: An Incorrect Access Control vulnerability was found in /smsa/view_marks.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view MARKS details.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-284
References: https://github.com/takekaramey/CVE_Writeup/blob/main/Kashipara/Responsive%20School%20Management%20System%20v3.2.0/Broken%20Access%20Control%20-%20Admin%20-%20View%20Marks.pdf; https://www.kashipara.com/project/php/12362/responsive-school-management-system-php-project-source-code
CVE: CVE-2024-41244
Published: 2024-08-07
Description: An Incorrect Access Control vulnerability was found in /smsa/view_class.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view CLASS details.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-284
References: https://github.com/takekaramey/CVE_Writeup/blob/main/Kashipara/Responsive%20School%20Management%20System%20v3.2.0/Broken%20Access%20Control%20-%20Admin%20-%20View%20Class.pdf
CVE: CVE-2024-41245
Published: 2024-08-07
Description: An Incorrect Access Control vulnerability was found in /smsa/view_teachers.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view TEACHER details.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-284
References: https://github.com/takekaramey/CVE_Writeup/blob/main/Kashipara/Responsive%20School%20Management%20System%20v3.2.0/Broken%20Access%20Control%20-%20Admin%20-%20View%20Teachers.pdf; https://www.kashipara.com/project/php/12362/responsive-school-management-system-php-project-source-code
CVE: CVE-2024-41250
Published: 2024-08-07
Description: An Incorrect Access Control vulnerability was found in /smsa/view_students.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view STUDENT details.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-284
References: https://github.com/takekaramey/CVE_Writeup/blob/main/Kashipara/Responsive%20School%20Management%20System%20v3.2.0/Broken%20Access%20Control%20-%20Admin%20-%20View%20Students.pdf
CVE: CVE-2024-7061
Published: 2024-08-07
Description: Okta Verify for Windows is vulnerable to privilege escalation through DLL hijacking. The vulnerability is fixed in Okta Verify for Windows version 5.0.2. To remediate this vulnerability, upgrade to 5.0.2 or greater.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-22, CWE-427, CWE-427
References: https://help.okta.com/oie/en-us/content/topics/releasenotes/oie-ov-release-notes.htm#panel4; https://trust.okta.com/security-advisories/okta-verify-for-windows-privilege-escalation-cve-2024-7061/