Page 154 of 3657 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: netlink: af_netlink: Prevent empty skb by adding a check on len. Adding a check on len parameter to avoid empty skb. This prevents a division error in netem_enqueue function which is caused when skb->len=0 and skb->data_len=0 in the randomized corruption step as shown below. skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8); Crash Report: [ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 [ 343.216110] netem: version 1.3 [ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+ [ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 [ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem] [ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f 74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03 [ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246 [ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX: 0000000000000000 [ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI: ffff88800f8eda40 [ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09: ffffffff94fb8445 [ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12: 0000000000000000 [ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15: 0000000000000020 [ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000) knlGS:0000000000000000 [ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4: 00000000000006e0 [ 343.250076] Call Trace: [ 343.250423] <TASK> [ 343.250713] ? memcpy+0x4d/0x60 [ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem] [ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem] [ 343.253102] ? • https://git.kernel.org/stable/c/c54a60c8fbaa774f828e26df79f66229a8a0e010 https://git.kernel.org/stable/c/40cf2e058832d9cfaae98dfd77334926275598b6 https://git.kernel.org/stable/c/54e785f7d5c197bc06dbb8053700df7e2a093ced https://git.kernel.org/stable/c/ff3f517bf7138e01a17369042908a3f345c0ee41 https://git.kernel.org/stable/c/c0315e93552e0d840e9edc6abd71c7db82ec8f51 https://git.kernel.org/stable/c/dadce61247c6230489527cc5e343b6002d1114c5 https://git.kernel.org/stable/c/4c986072a8c9249b9398c7a18f216dc26a9f0e35 https://git.kernel.org/stable/c/f123cffdd8fe8ea6c7fded4b88516a427 • CWE-369: Divide By Zero •

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

In the Linux kernel, the following vulnerability has been resolved: mac80211: track only QoS data frames for admission control For admission control, obviously all of that only works for QoS data frames, otherwise we cannot even access the QoS field in the header. Syzbot reported (see below) an uninitialized value here due to a status of a non-QoS nullfunc packet, which isn't even long enough to contain the QoS header. Fix this to only do anything for QoS data packets. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: rastrea solo frameworks de datos QoS para control de admisión. Para el control de admisión, obviamente todo eso solo funciona para frameworks de datos QoS; de lo contrario, ni siquiera podemos acceder al campo QoS en el encabezado. Syzbot informó (ver más abajo) un valor no inicializado aquí debido al estado de un paquete nullfunc sin QoS, que ni siquiera es lo suficientemente largo para contener el encabezado de QoS. Solucione este problema para hacer algo únicamente con los paquetes de datos QoS. • https://git.kernel.org/stable/c/02219b3abca59fca81711bfe7ee78df7abad97ce https://git.kernel.org/stable/c/69f054d6642c8f6173724ce17e7ee3ff66b8f682 https://git.kernel.org/stable/c/46b9e29db2012a4d2a40a26101862e002ccf387b https://git.kernel.org/stable/c/eed897a22230e3231a740eddd7d6d95ba476625f https://git.kernel.org/stable/c/42d08e97b196479f593499e887a9ab81446a34b9 https://git.kernel.org/stable/c/d5e568c3a4ec2ddd23e7dc5ad5b0c64e4f22981a •

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

In the Linux kernel, the following vulnerability has been resolved: dm btree remove: fix use after free in rebalance_children() Move dm_tm_unlock() after dm_tm_dec(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm btree remove: corrige el use after free en rebalance_children() Mueve dm_tm_unlock() después de dm_tm_dec(). • https://git.kernel.org/stable/c/a48f6a2bf33734ec5669ee03067dfb6c5b4818d6 https://git.kernel.org/stable/c/66ea642af6fd4eacb5d0271a922130fcf8700424 https://git.kernel.org/stable/c/b03abd0aa09c05099f537cb05b8460c4298f0861 https://git.kernel.org/stable/c/293f957be5e39720778fb1851ced7f5fba6d51c3 https://git.kernel.org/stable/c/501ecd90efdc9b2edc6c28852ecd098a4adf8f00 https://git.kernel.org/stable/c/0e21e6cd5eebfc929ac5fa3b97ca2d4ace3cb6a3 https://git.kernel.org/stable/c/607beb420b3fe23b948a9bf447d993521a02fbbb https://git.kernel.org/stable/c/1b8d2789dad0005fd5e7d35dab26a8e12 •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: use latest_dev in btrfs_show_devname The test case btrfs/238 reports the warning below: WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs] CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: btrfs_show_devname+0x108/0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 invoke_syscall+0x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x198/0x19c Reason: While btrfs_prepare_sprout() moves the fs_devices::devices into fs_devices::seed_list, the btrfs_show_devname() searches for the devices and found none, leading to the warning as in above. Fix: latest_dev is updated according to the changes to the device list. That means we could use the latest_dev->name to show the device name in /proc/self/mounts, the pointer will be always valid as it's assigned before the device is deleted from the list in remove or replace. The RCU protection is sufficient as the device structure is freed after synchronization. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: utilice Latest_dev en btrfs_show_devname El caso de prueba btrfs/238 informa la siguiente advertencia: ADVERTENCIA: CPU: 3 PID: 481 en fs/btrfs/super.c:2509 btrfs_show_devname+0x104 /0x1e8 [btrfs] CPU: 2 PID: 1 Comunicación: systemd Contaminado: GWO 5.14.0-rc1-custom #72 Nombre de hardware: QEMU Máquina virtual QEMU, BIOS 0.0.0 06/02/2015 Rastreo de llamadas: btrfs_show_devname+0x108/ 0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler +0x84/0xe4 el0t_64_sync+0x198/0x19c Motivo: mientras btrfs_prepare_sprout() mueve fs_devices::devices a fs_devices::seed_list, btrfs_show_devname() busca los dispositivos y no encuentra ninguno, lo que genera la advertencia como se muestra arriba. Solución: last_dev se actualiza según los cambios en la lista de dispositivos. Eso significa que podríamos usar el último_dev-&gt;name para mostrar el nombre del dispositivo en /proc/self/mounts, el puntero siempre será válido tal como está asignado antes de que el dispositivo se elimine de la lista en eliminar o reemplazar. La protección de la RCU es suficiente, ya que la estructura del dispositivo se libera después de la sincronización. • https://git.kernel.org/stable/c/e342c2558016ead462f376b6c6c2ac5efc17f3b1 https://git.kernel.org/stable/c/6605fd2f394bba0a0059df2b6cfc87b0b6d393a2 •

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

In the Linux kernel, the following vulnerability has been resolved: inet_diag: fix kernel-infoleak for UDP sockets KMSAN reported a kernel-infoleak [1], that can exploited by unpriv users. After analysis it turned out UDP was not initializing r->idiag_expires. Other users of inet_sk_diag_fill() might make the same mistake in the future, so fix this in inet_sk_diag_fill(). [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:156 [inline] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [inline] new_sync_read fs/read_write.c:400 [inline] vfs_read+0x1631/0x1980 fs/read_write.c:481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [inline] __se_sys_read fs/read_write.c:627 [inline] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Bytes 68-71 of 312 are uninitialized Memory access of size 312 starts at ffff88812ab54000 Data copied to user address 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet_diag: corrige la fuga de información del kernel para sockets UDP KMSAN informó una fuga de información del kernel [1], que puede ser explotada por usuarios sin privilegios. Después del análisis resultó que UDP no estaba inicializando r-&gt;idiag_expires. Otros usuarios de inet_sk_diag_fill() podrían cometer el mismo error en el futuro, así que solucione este problema en inet_sk_diag_fill(). [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:121 [en línea] ERROR: KMSAN: kernel-infoleak en copia lib/iov_iter.c:156 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [en línea] copia lib/iov_iter.c:156 [en línea] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [en línea] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram .c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [en línea] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [en línea] sock_recvmsg net/socket.c:962 [en línea] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [en línea] new_sync_read fs/read_write.c:400 [en línea] vfs_read+0x1631/0x1980 fs/read_write.c: 481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [en línea] __se_sys_read fs/read_write.c:627 [en línea] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 _arco x64/ x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit se creó en: slab_post_alloc_hook mm/slab.h:524 [en línea] slab_alloc_node mm/slub.c:3251 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en línea] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [en línea] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c: 1319 [en línea] netlink_unicast+0x1095/0x1360 netLink/af_netlink.c: 1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_etlink.c: 1916 sockm. C: 704 [ en línea] sock_sendmsg net/socket.c:724 [en línea] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:9 24 [en línea] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [en línea] __se_sys_writev fs/read_write.c:1037 [en línea] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 _syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Los bytes 68-71 de 312 no están inicializados El acceso a la memoria de tamaño 312 comienza en ffff88812ab54000 Datos copiados a la dirección de usuario 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 • https://git.kernel.org/stable/c/3c4d05c8056724aff3abc20650807dd828fded54 https://git.kernel.org/stable/c/7b5596e531253ce84213d9daa7120b71c9d83198 https://git.kernel.org/stable/c/3a4f6dba1eb98101abc012ef968a8b10dac1ce50 https://git.kernel.org/stable/c/e5d28205bf1de7082d904ed277ceb2db2879e302 https://git.kernel.org/stable/c/71ddeac8cd1d217744a0e060ff520e147c9328d1 •