Page 264 of 2735 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free of encap entry in neigh update handler Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock removal from TC filter update path and properly handle concurrent encap entry insertion/deletion which can lead to following use-after-free: [23827.464923] ================================================================== [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core] [23827.476731] Call Trace: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? • https://git.kernel.org/stable/c/2a1f1768fa17805ca2e937e2e034a7c3433d3bdc https://git.kernel.org/stable/c/b6447b72aca571632e71bb73a797118d5ce46a93 https://git.kernel.org/stable/c/fb1a3132ee1ac968316e45d21a48703a6db0b6c3 •

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 •