Page 104 of 4015 results (0.015 seconds)

CVSS: 8.4EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: phylib: fix potential use-after-free Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phylib: corrige el posible use-after-free. Commit bafbdd527d56 ("phylib: agregue soporte GPIO para restablecer el dispositivo") se agregó una llamada a phy_device_reset(phydev) después de la llamada put_device() en phy_detach( ). El comentario antes de la llamada put_device() dice que phydev podría desaparecer con put_device(). Solucione el posible use-after-free llamando a phy_device_reset() antes de put_device(). • https://git.kernel.org/stable/c/bafbdd527d569c8200521f2f7579f65a044271be https://git.kernel.org/stable/c/67d271760b037ce0806d687ee6057edc8afd4205 https://git.kernel.org/stable/c/f39027cbada43b33566c312e6be3db654ca3ad17 https://git.kernel.org/stable/c/bd024e36f68174b1793906c39ca16cee0c9295c2 https://git.kernel.org/stable/c/aefaccd19379d6c4620269a162bfb88ff687f289 https://git.kernel.org/stable/c/cb2fab10fc5e7a3aa1bb0a68a3abdcf3e37852af https://git.kernel.org/stable/c/cbda1b16687580d5beee38273f6241ae3725960c https://access.redhat.com/security/cve/CVE-2022-48754 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/smc: Transitional solution for clcsock race issue We encountered a crash in smc_setsockopt() and it is caused by accessing smc->clcsock after clcsock was released. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53 RIP: 0010:smc_setsockopt+0x59/0x280 [smc] Call Trace: <TASK> __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f16ba83918e </TASK> This patch tries to fix it by holding clcsock_release_lock and checking whether clcsock has already been released before access. In case that a crash of the same reason happens in smc_getsockopt() or smc_switch_to_fallback(), this patch also checkes smc->clcsock in them too. And the caller of smc_switch_to_fallback() will identify whether fallback succeeds according to the return value. • https://git.kernel.org/stable/c/fd57770dd198f5b2ddd5b9e6bf282cf98d63adb9 https://git.kernel.org/stable/c/d1d004585b40c212b338fc8a40cbaaf230ea4703 https://git.kernel.org/stable/c/38f0bdd548fd2ef5d481b88d8a2bfef968452e34 https://git.kernel.org/stable/c/4284225cd8001e134f5cf533a7cd244bbb654d0f https://git.kernel.org/stable/c/c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760 •

CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el desplazamiento incorrecto en bio_truncate() bio_truncate() borra el búfer fuera del último bloque de bdev, sin embargo, el bio_truncate() actual está usando el desplazamiento de página incorrecto. Entonces puede devolver los datos no inicializados. Esto sucedió cuando tanto el FS truncado/corrupto como el espacio de usuario (a través de bdev) intentaban leer lo último de bdev. • https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8 https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82 https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3 https://access.redhat.com/security/cve/CVE-2022-48747 https://bugzilla.redhat.com/show_bug.cgi?id=2293312 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-908: Use of Uninitialized Resource •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). • https://git.kernel.org/stable/c/b5503b994ed5ed8dbfe821317e7b5b38acb065c5 https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67 •

CVSS: 4.4EPSS: 0%CPEs: 10EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. • https://git.kernel.org/stable/c/fafc9555d87a19c78bcd43ed731c3a73bf0b37a9 https://git.kernel.org/stable/c/622c36f143fc9566ba49d7cec994c2da1182d9e2 https://git.kernel.org/stable/c/ae43f9360a21b35cf785ae9a0fdce524d7af0938 https://git.kernel.org/stable/c/ae9d577f3dbb686862b7d0dc9cc73054f0964d4d https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26 https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486 • CWE-124: Buffer Underwrite ('Buffer Underflow') •