CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47404 – HID: betop: fix slab-out-of-bounds Write in betop_probe
https://notcve.org/view.php?id=CVE-2021-47404
In the Linux kernel, the following vulnerability has been resolved: HID: betop: fix slab-out-of-bounds Write in betop_probe Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption. So this patch checks hid_device's input is non empty before it's been used. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: betop: corrige escritura slab-out-of-bounds en betop_probe. Syzbot informó un error de escritura slab-out-of-bounds en el controlador hid-betopff. El problema es que el controlador supone que el dispositivo debe tener un informe de entrada, pero algunos dispositivos maliciosos violan esta suposición. Entonces, este parche verifica que la entrada de hid_device no esté vacía antes de usarse. • https://git.kernel.org/stable/c/a4faa7153b87fbcfe4be15f4278676f79ca6e019 https://git.kernel.org/stable/c/6fc4476dda58f6c00097c7ddec3b772513f57525 https://git.kernel.org/stable/c/1c83c38dec83d57bc18d0c01d82c413d3b34ccb9 https://git.kernel.org/stable/c/bb8b72374db69afa25a5b65cf1c092860c6fe914 https://git.kernel.org/stable/c/fe9bb925e7096509711660d39c0493a1546e9550 https://git.kernel.org/stable/c/dedfc35a2de2bae9fa3da8210a05bfd515f83fee https://git.kernel.org/stable/c/708107b80aa616976d1c5fa60ac0c1390749db5e https://git.kernel.org/stable/c/1e4ce418b1cb1a810256b5fb3fd33d22d •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47403 – ipack: ipoctal: fix module reference leak
https://notcve.org/view.php?id=CVE-2021-47403
In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix module reference leak A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped. Fix this by taking the module reference and initialising the tty driver data when installing the tty. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipack: ipoctal: reparar fuga de referencia del módulo. Se tomó una referencia al módulo portador en cada apertura, pero solo se publicó una vez cuando se eliminó la referencia final a la estructura tty. Solucione este problema tomando la referencia del módulo e inicializando los datos del controlador tty al instalar el tty. • https://git.kernel.org/stable/c/82a82340bab6c251e0705339f60763718eaa2a22 https://git.kernel.org/stable/c/31398849b84ebae0d43a1cf379cb9895597f221a https://git.kernel.org/stable/c/c0adb5a947dec6cff7050ec56d78ecd3916f9ce6 https://git.kernel.org/stable/c/dde4c1429b97383689f755ce92b4ed1e84a9c92b https://git.kernel.org/stable/c/9c5b77a7ffc983b2429ce158b50497c5d3c86a69 https://git.kernel.org/stable/c/3253c87e1e5bc0107aab773af2f135ebccf38666 https://git.kernel.org/stable/c/7cea848678470daadbfdaa6a112b823c290f900c https://git.kernel.org/stable/c/811178f296b16af30264def74c8d2179a • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47401 – ipack: ipoctal: fix stack information leak
https://notcve.org/view.php?id=CVE-2021-47401
In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix stack information leak The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops). Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice. Fixing the ABI is a separate issue, but this at least plugs the security hole. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipack: ipoctal: corrige la fuga de información de la pila. El nombre del controlador tty también se usa después de registrar el controlador y específicamente no debe asignarse en la pila para evitar filtrar información al espacio del usuario (o activar un ups). Los controladores no deberían intentar codificar información de topología en el nombre del dispositivo tty, pero este se coló durante la preparación sin que nadie se diera cuenta y desde entonces otro controlador copió esta mala práctica. Arreglar la ABI es un tema aparte, pero esto al menos tapa el agujero de seguridad. • https://git.kernel.org/stable/c/ba4dc61fe8c545a5d6a68b63616776556b771f51 https://git.kernel.org/stable/c/acb96e782bad427ca4bb1bd94af660acd1462380 https://git.kernel.org/stable/c/741ea2670e021350e54f491106bdaa22dc50e6a0 https://git.kernel.org/stable/c/2725925982dc96a78069cd118ea3d66759bfdad7 https://git.kernel.org/stable/c/829f13d6079cf7a2465522f39acb43033e9b320d https://git.kernel.org/stable/c/8657158a3b68c85234e6da3d8eae33d6183588b7 https://git.kernel.org/stable/c/5f6a309a699675680df15d9b6d389114515b4426 https://git.kernel.org/stable/c/0a9c36a2e06a249acbed64e8e0b84637c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47397 – sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
https://notcve.org/view.php?id=CVE-2021-47397
In the Linux kernel, the following vulnerability has been resolved: sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb We should always check if skb_header_pointer's return is NULL before using it, otherwise it may cause null-ptr-deref, as syzbot reported: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: <IRQ> sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: se rompe si skb_header_pointer devuelve NULL en sctp_rcv_ootb. Siempre debemos verificar si el retorno de skb_header_pointer es NULL antes de usarlo; de lo contrario, puede causar null-ptr-deref, como informó syzbot: KASAN : null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [en línea] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input .c:196 Seguimiento de llamadas : sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 incluir/linux /netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [en línea] ip6_rcv_finish net/ipv6/ip6_input.c:76 [en línea] NF_HOOK include/linux/netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c :297 • https://git.kernel.org/stable/c/3acb50c18d8d6650f10919464ade4dcdaf41d62f https://git.kernel.org/stable/c/77bc7dcf0fcc1519341a91788d7a2914fcfddf6d https://git.kernel.org/stable/c/8c630a7b4f9dec63f08bd881ab77984a724a5124 https://git.kernel.org/stable/c/ec018021cf445abbe8e2f3e2a7f1dcc813cb8ea1 https://git.kernel.org/stable/c/9c6591ae8e63f93c895ad5e2703c36c548aac997 https://git.kernel.org/stable/c/8180611c238e11676612eb2a9828b1c7a3a4d77b https://git.kernel.org/stable/c/f7e745f8e94492a8ac0b0a26e25f2b19d342918f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47396 – mac80211-hwsim: fix late beacon hrtimer handling
https://notcve.org/view.php?id=CVE-2021-47396
In the Linux kernel, the following vulnerability has been resolved: mac80211-hwsim: fix late beacon hrtimer handling Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx that our handling of the hrtimer here is wrong: If the timer fires late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot) then it tries to actually rearm the timer at the next deadline, which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired here The next time it fires, it's later, but will still try to schedule for the next deadline (now 3), etc. until it catches up with N, but that might take a long time, causing stalls etc. Now, all of this is simulation, so we just have to fix it, but note that the behaviour is wrong even per spec, since there's no value then in sending all those beacons unaligned - they should be aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a bit (or a lot) late, then just resume at that point. Therefore, change the code to use hrtimer_forward_now() which will ensure that the next firing of the timer would be at N+1 (in the picture), i.e. the next interval point after the current time. • https://git.kernel.org/stable/c/01e59e467ecf976c782eecd4dc99644802cc60e2 https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05 https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7 https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572 •