Page 395 of 2867 results (0.050 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16() If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb_strndup_from_utf16() Si ->NameOffset de smb2_create_req es menor que el desplazamiento del búfer de smb2_create_req, puede ocurrir una lectura de slab-out-of-bounds de smb2_open. Este parche establece el valor mínimo del desplazamiento del nombre en el desplazamiento del búfer para validar la longitud del nombre de smb2_create_req(). • https://git.kernel.org/stable/c/3b8da67191e938a63d2736dabb4ac5d337e5de57 https://git.kernel.org/stable/c/4f97e6a9d62cb1fce82fbf4baff44b83221bc178 https://git.kernel.org/stable/c/a80a486d72e20bd12c335bcd38b6e6f19356b0aa •

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

In the Linux kernel, the following vulnerability has been resolved: net: esp: fix bad handling of pages from page_pool When the skb is reorganized during esp_output (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through put_page. But if the skb fragment pages are originating from a page_pool, calling put_page on them will trigger a page_pool leak which will eventually result in a crash. This leak can be easily observed when using CONFIG_DEBUG_VM and doing ipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? • https://git.kernel.org/stable/c/6a5bcd84e886a9a91982e515c539529c28acdcc2 https://git.kernel.org/stable/c/8291b4eac429c480386669444c6377573f5d8664 https://git.kernel.org/stable/c/1abb20a5f4b02fb3020f88456fc1e6069b3cdc45 https://git.kernel.org/stable/c/f278ff9db67264715d0d50e3e75044f8b78990f4 https://git.kernel.org/stable/c/c3198822c6cb9fb588e446540485669cc81c5d34 https://access.redhat.com/security/cve/CVE-2024-26953 https://bugzilla.redhat.com/show_bug.cgi?id=2278193 •

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

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial out-of-bounds when buffer offset is invalid I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige posibles límites cuando el desplazamiento del búfer no es válido. Encontré posibles límites cuando los campos de desplazamiento del búfer de algunas solicitudes no son válidos. Este parche establece el valor mínimo del campo de compensación del búfer en -&gt;Desplazamiento del búfer para validar la longitud del búfer. • https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63 https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5 https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: check for dangling peer via is_dead instead of empty list If all peers are removed via wg_peer_remove_all(), rather than setting peer_list to empty, the peer is added to a temporary list with a head on the stack of wg_peer_remove_all(). If a netlink dump is resumed and the cursored peer is one that has been removed via wg_peer_remove_all(), it will iterate from that peer and then attempt to dump freed peers. Fix this by instead checking peer->is_dead, which was explictly created for this purpose. Also move up the device_update_lock lockdep assertion, since reading is_dead relies on that. It can be reproduced by a small script like: echo "Setting config..." ip link add dev wg0 type wireguard wg setconf wg0 /big-config ( while true; do echo "Showing config..." wg showconf wg0 > /dev/null done ) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resulting in: BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20 Read of size 8 at addr ffff88811956ec70 by task wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c/0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: netlink: verifique si hay pares pendientes a través de is_dead en lugar de una lista vacía. • https://git.kernel.org/stable/c/e7096c131e5161fa3b8e52a650d7719d2857adfd https://git.kernel.org/stable/c/f52be46e3e6ecefc2539119784324f0cbc09620a https://git.kernel.org/stable/c/710a177f347282eea162aec8712beb1f42d5ad87 https://git.kernel.org/stable/c/b7cea3a9af0853fdbb1b16633a458f991dde6aac https://git.kernel.org/stable/c/13d107794304306164481d31ce33f8fdb25a9c04 https://git.kernel.org/stable/c/7bedfe4cfa38771840a355970e4437cd52d4046b https://git.kernel.org/stable/c/302b2dfc013baca3dea7ceda383930d9297d231d https://git.kernel.org/stable/c/55b6c738673871c9b0edae05d0c97995c •

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

In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wireguard: netlink: acceda al dispositivo a través de ctx en lugar de peer. el commit anterior solucionó un error que provocaba que se desreferenciara un dispositivo NULL peer-&gt;. • https://git.kernel.org/stable/c/e7096c131e5161fa3b8e52a650d7719d2857adfd https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068 https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5 https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5 https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37 https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996 https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47 https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971 •