Page 193 of 4765 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: udp: fix race between close() and udp_abort() Kaustubh reported and diagnosed a panic in udp_lib_lookup(). The root cause is udp_abort() racing with close(). Both racing functions acquire the socket lock, but udp{v6}_destroy_sock() release it before performing destructive actions. We can't easily extend the socket lock scope to avoid the race, instead use the SOCK_DEAD flag to prevent udp_abort from doing any action when the critical race happens. Diagnosed-and-tested-by: Kaustubh Pandey <kapandey@codeaurora.org> En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: udp: corrige la ejecución entre close() y udp_abort(). Kaustubh informó y diagnosticó un pánico en udp_lib_lookup(). La causa principal es que udp_abort() compite con close(). Ambas funciones de ejecución adquieren el bloqueo del socket, pero udp{v6}_destroy_sock() lo libera antes de realizar acciones destructivas. • https://git.kernel.org/stable/c/5d77dca82839ef016a93ad7acd7058b14d967752 https://git.kernel.org/stable/c/e3c36c773aed0fef8b1d3d555b43393ec564400f https://git.kernel.org/stable/c/a0882f68f54f7a8b6308261acee9bd4faab5a69e https://git.kernel.org/stable/c/2f73448041bd0682d4b552cfd314ace66107f1ad https://git.kernel.org/stable/c/5a88477c1c85e4baa51e91f2d40f2166235daa56 https://git.kernel.org/stable/c/8729ec8a2238152a4afc212a331a6cd2c61aeeac https://git.kernel.org/stable/c/65310b0aff86980a011c7c7bfa487a333d4ca241 https://git.kernel.org/stable/c/a8b897c7bcd47f4147d066e22cc01d102 •

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix page reclaim for dead peer hairpin When adding a hairpin flow, a firmware-side send queue is created for the peer net device, which claims some host memory pages for its internal ring buffer. If the peer net device is removed/unbound before the hairpin flow is deleted, then the send queue is not destroyed which leads to a stack trace on pci device remove: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource [ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110 [ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0 [ 748.002171] ------------[ cut here ]------------ [ 748.001177] FW pages counter is 4 after reclaiming all pages [ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286 [ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 748.001654] Call Trace: [ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [ 748.001354] ? • https://git.kernel.org/stable/c/4d8fcf216c90bc25e34ae2200aa8985ee3158898 https://git.kernel.org/stable/c/4b16118665e94c90a3e84a5190486fd0e4eedd74 https://git.kernel.org/stable/c/be7f3f401d224e1efe8112b2fa8b837eeb8c5e52 https://git.kernel.org/stable/c/b374c1304f6d3d4752ad1412427b7bf02bb1fd61 https://git.kernel.org/stable/c/a3e5fd9314dfc4314a9567cde96e1aef83a7458a •

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: Fix out of bounds when parsing TCP options The TCP option parser in synproxy (synproxy_parse_options) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added an early return when length < 0 to avoid calling skb_header_pointer with negative length. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: synproxy: corrección de límites al analizar opciones TCP. El analizador de opciones TCP en synproxy (synproxy_parse_options) podría leer un byte fuera de los límites. Cuando la longitud es 1, el flujo de ejecución entra en el bucle, lee un byte del código de operación y, si el código de operación no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte más, que excede la longitud de 1. • https://git.kernel.org/stable/c/48b1de4c110a7afa4b85862f6c75af817db26fad https://git.kernel.org/stable/c/e1eb98cfeafdd85537e7e3cefe93ca9bfbcc3ea8 https://git.kernel.org/stable/c/576c1526b4d83c44ad7b673cb841f36cbc6cb6c4 https://git.kernel.org/stable/c/674b5f0c6a4fc5d3abce877048290cea6091fcb1 https://git.kernel.org/stable/c/7d9a9a1a88a3da574e019b4de756bc73337b3b0b https://git.kernel.org/stable/c/6defc77d48eff74075b80ad5925061b2fc010d98 https://git.kernel.org/stable/c/9cdf299ba4e153b5e56187648420de22c6216f02 https://git.kernel.org/stable/c/f648089337cb8ed40b2bb96e244f72b9d •

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

In the Linux kernel, the following vulnerability has been resolved: sch_cake: Fix out of bounds when parsing TCP options and header The TCP option parser in cake qdisc (cake_get_tcpopt and cake_tcph_may_drop) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP header. Although it wasn't strictly an out-of-bounds access (memory was allocated), garbage values could be read where CAKE expected the TCP header if doff was smaller than 5. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sch_cake: Corrección de límites al analizar las opciones TCP y el encabezado. El analizador de opciones TCP en cake qdisc (cake_get_tcpopt y cake_tcph_may_drop) podía leer un byte fuera de los límites. • https://git.kernel.org/stable/c/8b7138814f29933898ecd31dfc83e35a30ee69f5 https://git.kernel.org/stable/c/595897ef118d6fe66690c4fc5b572028c9da95b7 https://git.kernel.org/stable/c/4cefa061fc63f4d2dff5ab4083f43857cd7a2335 https://git.kernel.org/stable/c/3b491dd593d582ceeb27aa617600712a6bd14246 https://git.kernel.org/stable/c/3371392c60e2685af30bd4547badd880f5df2b3f https://git.kernel.org/stable/c/ba91c49dedbde758ba0b72f57ac90b06ddf8e548 •

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

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix OOB Read in qrtr_endpoint_post Syzbot reported slab-out-of-bounds Read in qrtr_endpoint_post. The problem was in wrong _size_ type: if (len != ALIGN(size, 4) + hdrlen) goto err; If size from qrtr_hdr is 4294967293 (0xfffffffd), the result of ALIGN(size, 4) will be 0. In case of len == hdrlen and size == 4294967293 in header this check won't fail and skb_put_data(skb, data + hdrlen, size); will read out of bound from data, which is hdrlen allocated block. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qrtr: arreglar OOB Lectura en qrtr_endpoint_post. • https://git.kernel.org/stable/c/194ccc88297ae78d0803adad83c6dcc369787c9e https://git.kernel.org/stable/c/f8111c0d7ed42ede41a3d0d393b104de0730a8a6 https://git.kernel.org/stable/c/26b8d10703a9be45d6097946b2b4011f7dd2c56f https://git.kernel.org/stable/c/960b08dd36de1e341e3eb43d1c547513e338f4f8 https://git.kernel.org/stable/c/19892ab9c9d838e2e5a7744d36e4bb8b7c3292fe https://git.kernel.org/stable/c/ad9d24c9429e2159d1e279dc3a83191ccb4daf1d •