CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47240 – net: qrtr: fix OOB Read in qrtr_endpoint_post
https://notcve.org/view.php?id=CVE-2021-47240
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47239 – net: usb: fix possible use-after-free in smsc75xx_bind
https://notcve.org/view.php?id=CVE-2021-47239
In the Linux kernel, the following vulnerability has been resolved: net: usb: fix possible use-after-free in smsc75xx_bind The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind") fails to clean up the work scheduled in smsc75xx_reset-> smsc75xx_set_multicast, which leads to use-after-free if the work is scheduled to start after the deallocation. In addition, this patch also removes a dangling pointer - dev->data[0]. This patch calls cancel_work_sync to cancel the scheduled work and set the dangling pointer to NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:usb: corrige posible use after free en smsc75xx_bind. La confirmación 46a8b29c6306 ("net:usb: corrige la pérdida de memoria en smsc75xx_bind") no logra limpiar el trabajo programado en smsc75xx_reset -> smsc75xx_set_multicast, lo que genera use after free si el trabajo está programado para comenzar después de la desasignación. Además, este parche también elimina un puntero colgante: dev->data[0]. • https://git.kernel.org/stable/c/200dbfcad8011e50c3cec269ed7b980836eeb1fa https://git.kernel.org/stable/c/22c840596af0c09068b6cf948616e6496e59e07f https://git.kernel.org/stable/c/9e6b8c1ff9d997e1fa16cbd2d60739adf6dc1bbc https://git.kernel.org/stable/c/9e6a3eccb28779710cbbafc4f4258d92509c6d07 https://git.kernel.org/stable/c/b95fb96e6339e34694dd578fb6bde3575b01af17 https://git.kernel.org/stable/c/635ac38b36255d3cfb8312cf7c471334f4d537e0 https://git.kernel.org/stable/c/70c886ac93f87ae7214a0c69151a28a8075dd95b https://git.kernel.org/stable/c/7cc8b2e05fcea6edd022d26e82091d781 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47238 – net: ipv4: fix memory leak in ip_mc_add1_src
https://notcve.org/view.php?id=CVE-2021-47238
In the Linux kernel, the following vulnerability has been resolved: net: ipv4: fix memory leak in ip_mc_add1_src BUG: memory leak unreferenced object 0xffff888101bc4c00 (size 32): comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline] [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline] [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline] [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline] [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423 [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline] [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline] [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47 [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed, because it was also called in igmpv3_clear_delrec(). Rough callgraph: inetdev_destroy -> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src -> RCU_INIT_POINTER(dev->ip_ptr, NULL) However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through inetdev_by_index() and then in_dev->mc_list->sources cannot be released by ip_mc_del1_src() in the sock_close. Rough call sequence goes like: sock_close -> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_src So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free in_dev->mc_list->sources. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: corrige la pérdida de memoria en ip_mc_add1_src. • https://git.kernel.org/stable/c/24803f38a5c0b6c57ed800b47e695f9ce474bc3a https://git.kernel.org/stable/c/bd1b664a19403ede448d29c87b2f23796bc7a577 https://git.kernel.org/stable/c/b38c6e0bd5b5e439ecebdc0df599d573c2f610f8 https://git.kernel.org/stable/c/0dc13e75507faa17ac9f7562b4ef7bf8fcd78422 https://git.kernel.org/stable/c/6cff57eea3347f79f1867cc53e1093b6614138d8 https://git.kernel.org/stable/c/1e28018b5c83d5073f74a6fb72eabe8370b2f501 https://git.kernel.org/stable/c/3dd2aeac2e9624cff9fa634710837e4f2e352758 https://git.kernel.org/stable/c/ac31cc837cafb57a271babad8ccffbf73 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47237 – net: hamradio: fix memory leak in mkiss_close
https://notcve.org/view.php?id=CVE-2021-47237
In the Linux kernel, the following vulnerability has been resolved: net: hamradio: fix memory leak in mkiss_close My local syzbot instance hit memory leak in mkiss_open()[1]. The problem was in missing free_netdev() in mkiss_close(). In mkiss_open() netdevice is allocated and then registered, but in mkiss_close() netdevice was only unregistered, but not freed. Fail log: BUG: memory leak unreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310 [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0 [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0 [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hamradio: corrige la pérdida de memoria en mkiss_close. Mi instancia local de syzbot tuvo una pérdida de memoria en mkiss_open()[1]. El problema estaba en que faltaba free_netdev() en mkiss_close(). En mkiss_open() el dispositivo de red se asigna y luego se registra, pero en mkiss_close() el dispositivo de red solo se anula del registro, pero no se libera. • https://git.kernel.org/stable/c/815f62bf742718458ba822a7e1f51f285eb997f2 https://git.kernel.org/stable/c/c634ba0b4159838ff45a60d3a0ace3b4118077a5 https://git.kernel.org/stable/c/3942d0f9ace1a95a74930b5b4fc0e5005c62b37b https://git.kernel.org/stable/c/765a8a04f828db7222b36a42b1031f576bfe95c3 https://git.kernel.org/stable/c/c16c4716a1b5ba4f83c7e00da457cba06761f119 https://git.kernel.org/stable/c/a49cbb762ef20655f5c91abdc13658b0af5e159d https://git.kernel.org/stable/c/290b0b6432e2599021db0b8d6046f756d931c29f https://git.kernel.org/stable/c/f4de2b43d13b7cf3ced9310e371b90c83 •
CVSS: 5.1EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47236 – net: cdc_eem: fix tx fixup skb leak
https://notcve.org/view.php?id=CVE-2021-47236
In the Linux kernel, the following vulnerability has been resolved: net: cdc_eem: fix tx fixup skb leak when usbnet transmit a skb, eem fixup it in eem_tx_fixup(), if skb_copy_expand() failed, it return NULL, usbnet_start_xmit() will have no chance to free original skb. fix it by free orginal skb in eem_tx_fixup() first, then check skb clone status, if failed, return NULL to usbnet. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: cdc_eem: corrige la fuga de skb de reparación de tx cuando usbnet transmite un skb, eem lo repara en eem_tx_fixup(), si skb_copy_expand() falla, devuelve NULL, usbnet_start_xmit() No tendrá posibilidad de liberar el skb original. solucionelo primero con skb original gratuito en eem_tx_fixup(), luego verifique el estado del clon de skb, si falla, devuelva NULL a usbnet. • https://git.kernel.org/stable/c/9f722c0978b04acba209f8ca1896ad05814bc3a3 https://git.kernel.org/stable/c/f12554b0ff639e74612cc01b3b4a049e098d2d65 https://git.kernel.org/stable/c/14184ec5c958b589ba934da7363a2877879204df https://git.kernel.org/stable/c/1bcacd6088d61c0ac6a990d87975600a81f3247e https://git.kernel.org/stable/c/f4e6a7f19c82f39b1803e91c54718f0d7143767d https://git.kernel.org/stable/c/81de2ed06df8b5451e050fe6a318af3263dbff3f https://git.kernel.org/stable/c/05b2b9f7d24b5663d9b47427fe1555bdafd3ea02 https://git.kernel.org/stable/c/b4f7a9fc9d094c0c4a66f2ad7c37b1dbe • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •