CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2018-9423
https://notcve.org/view.php?id=CVE-2018-9423
In ihevcd_parse_slice_header of ihevcd_parse_slice_header.c there is a possible out of bound read due to missing bounds check. This could lead to denial of service with no additional execution privileges needed. • https://source.android.com/docs/security/bulletin/pixel/2018-07-01 • CWE-125: Out-of-bounds Read •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2024-53981 – python-multipart has a Denial of service (DoS) via deformation `multipart/form-data` boundary
https://notcve.org/view.php?id=CVE-2024-53981
When parsing form data, python-multipart skips line breaks (CR \r or LF \n) in front of the first boundary and any tailing bytes after the last boundary. ... An attacker could abuse this by sending a malicious request with lots of data before the first or after the last boundary, causing high CPU load and stalling the processing thread for a significant amount of time. In case of ASGI application, this could stall the event loop and prevent other requests from being processed, resulting in a denial of service (DoS). This vulnerability is fixed in 0.0.18. • https://github.com/Kludex/python-multipart/commit/c4fe4d3cebc08c660e57dd709af1ffa7059b3177 https://github.com/Kludex/python-multipart/security/advisories/GHSA-59g5-xgcq-4qw3 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 4.3EPSS: 0%CPEs: 1EXPL: 0CVE-2024-53984 – Nanopb does not release memory on error return when using PB_DECODE_DELIMITED
https://notcve.org/view.php?id=CVE-2024-53984
This could lead to memory leak and potential denial-of-service. • https://github.com/nanopb/nanopb/commit/2b86c255aa52250438d5aba124d0e86db495b378 https://github.com/nanopb/nanopb/security/advisories/GHSA-xwqq-qxmw-hj5r • CWE-401: Missing Release of Memory after Effective Lifetime CWE-755: Improper Handling of Exceptional Conditions •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53124 – net: fix data-races around sk->sk_forward_alloc
https://notcve.org/view.php?id=CVE-2024-53124
__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ fin del seguimiento 000000000000000 ]--- Es posible que dos subprocesos llamen a tcp_v6_do_rcv()/sk_forward_alloc_add() simultáneamente cuando sk->sk_state == TCP_LISTEN con sk->sk_lock desbloqueado, lo que desencadena una carrera de datos alrededor de sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // establecer variable local recuperable __sk_mem_reclaim sk_forward_alloc_add() En este caso de prueba de syzkaller, dos subprocesos llaman a tcp_v6_do_rcv() con skb->truesize=768, sk_forward_alloc cambia de esta manera: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 recuperable=7424 | | | sk_mem_uncharge() | +768 = 8192 | recuperable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 ! • https://git.kernel.org/stable/c/e994b2f0fb9229aeff5eea9541320bd7b2ca8714 https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6 https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53121 – net/mlx5: fs, lock FTE when checking if active
https://notcve.org/view.php?id=CVE-2024-53121
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? ... __ ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: fs, bloquear FTE al verificar si está activo Las confirmaciones a las que se hace referencia introdujeron un proceso de dos pasos para eliminar FTE: - Bloquear el FTE, eliminarlo del hardware, establecer la función de eliminación de hardware en NULL y desbloquear el FTE. - Bloquear el grupo de flujo principal, eliminar la copia de software del FTE y eliminarlo de la matriz x. • https://git.kernel.org/stable/c/718ce4d601dbf73b5dbe024a88c9e34168fe87f2 https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838 https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9 https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d5f7bef6 •