CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47367 – virtio-net: fix pages leaking when building skb in big mode
https://notcve.org/view.php?id=CVE-2021-47367
In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix pages leaking when building skb in big mode We try to use build_skb() if we had sufficient tailroom. But we forget to release the unused pages chained via private in big mode which will leak pages. Fixing this by release the pages after building the skb in big mode. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: corrige páginas con fugas al compilar skb en modo grande. Intentamos usar build_skb() si tuviéramos suficiente espacio de adaptación. • https://git.kernel.org/stable/c/fb32856b16ad9d5bcd75b76a274e2c515ac7b9d7 https://git.kernel.org/stable/c/f020bb63b5d2e5576acadd10e158fe3b04af67ba https://git.kernel.org/stable/c/afd92d82c9d715fb97565408755acad81573591a • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47366 – afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
https://notcve.org/view.php?id=CVE-2021-47366
In the Linux kernel, the following vulnerability has been resolved: afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value. This is a problem, however, since the file position and length fields of FS.FetchData are *signed* 32-bit values. Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values. This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that. Note that the issue does not exist with FS.StoreData - that uses *unsigned* 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values. This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index This can be observed in the server's FileLog with something like the following appearing: Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5 Note the file position of 18446744071815340032. This is the requested file position sign-extended. • https://git.kernel.org/stable/c/b9b1f8d5930a813879278d0cbfc8c658d6a038dc https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97 https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47365 – afs: Fix page leak
https://notcve.org/view.php?id=CVE-2021-47365
In the Linux kernel, the following vulnerability has been resolved: afs: Fix page leak There's a loop in afs_extend_writeback() that adds extra pages to a write we want to make to improve the efficiency of the writeback by making it larger. This loop stops, however, if we hit a page we can't write back from immediately, but it doesn't get rid of the page ref we speculatively acquired. This was caused by the removal of the cleanup loop when the code switched from using find_get_pages_contig() to xarray scanning as the latter only gets a single page at a time, not a batch. Fix this by putting the page on a ref on an early break from the loop. Unfortunately, we can't just add that page to the pagevec we're employing as we'll go through that and add those pages to the RPC call. This was found by the generic/074 test. It leaks ~4GiB of RAM each time it is run - which can be observed with "top". En el kernel de Linux, se resolvió la siguiente vulnerabilidad: afs: Reparar pérdida de página. Hay un bucle en afs_extend_writeback() que agrega páginas adicionales a una escritura que queremos realizar para mejorar la eficiencia de la escritura diferida haciéndola más grande. • https://git.kernel.org/stable/c/e87b03f5830ecd8ca21836d3ee48c74f8d58fa31 https://git.kernel.org/stable/c/d130b5fdd42254d92948d06347940276140c927e https://git.kernel.org/stable/c/581b2027af0018944ba301d68e7af45c6d1128b5 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47364 – comedi: Fix memory leak in compat_insnlist()
https://notcve.org/view.php?id=CVE-2021-47364
In the Linux kernel, the following vulnerability has been resolved: comedi: Fix memory leak in compat_insnlist() `compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST` ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to temporarily hold an array of `struct comedi_insn` converted from the 32-bit version in user space. This memory is only being freed if there is a fault while filling the array, otherwise it is leaked. Add a call to `kfree()` to fix the leak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Reparar pérdida de memoria en compat_insnlist() `compat_insnlist()` maneja la versión de 32 bits del ioctl `COMEDI_INSNLIST` (cuando `CONFIG_COMPAT` está habilitado). Asigna memoria para almacenar temporalmente una matriz de `struct comedi_insn` convertida desde la versión de 32 bits en el espacio de usuario. • https://git.kernel.org/stable/c/b8d47d8813055ce38c0d2ad913d5462017e52692 https://git.kernel.org/stable/c/8d6a21e4cd6a319b0662cbe4ad6199e276ac776a https://git.kernel.org/stable/c/f217b6c1e28ed0b353634ce4d92a155b80bd1671 https://git.kernel.org/stable/c/bb509a6ffed2c8b0950f637ab5779aa818ed1596 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47363 – nexthop: Fix division by zero while replacing a resilient group
https://notcve.org/view.php?id=CVE-2021-47363
In the Linux kernel, the following vulnerability has been resolved: nexthop: Fix division by zero while replacing a resilient group The resilient nexthop group torture tests in fib_nexthop.sh exposed a possible division by zero while replacing a resilient group [1]. The division by zero occurs when the data path sees a resilient nexthop group with zero buckets. The tests replace a resilient nexthop group in a loop while traffic is forwarded through it. The tests do not specify the number of buckets while performing the replacement, resulting in the kernel allocating a stub resilient table (i.e, 'struct nh_res_table') with zero buckets. This table should never be visible to the data path, but the old nexthop group (i.e., 'oldg') might still be used by the data path when the stub table is assigned to it. Fix this by only assigning the stub table to the old nexthop group after making sure the group is no longer used by the data path. Tested with fib_nexthops.sh: Tests passed: 222 Tests failed: 0 [1] divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:nexthop_select_path+0x2d2/0x1a80 [...] Call Trace: fib_select_multipath+0x79b/0x1530 fib_select_path+0x8fb/0x1c10 ip_route_output_key_hash_rcu+0x1198/0x2da0 ip_route_output_key_hash+0x190/0x340 ip_route_output_flow+0x21/0x120 raw_sendmsg+0x91d/0x2e10 inet_sendmsg+0x9e/0xe0 __sys_sendto+0x23d/0x360 __x64_sys_sendto+0xe1/0x1b0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nexthop: corrige la división por cero mientras se reemplaza un grupo resistente Las pruebas de tortura del grupo resiliente de nexthop en fib_nexthop.sh expusieron una posible división por cero mientras se reemplaza un grupo resistente [1]. La división por cero ocurre cuando la ruta de datos ve un grupo de nexthop resistente con cero depósitos. Las pruebas reemplazan un grupo nexthop resistente en un bucle mientras el tráfico se reenvía a través de él. • https://git.kernel.org/stable/c/283a72a5599e80750699d2021830a294ed9ab3f3 https://git.kernel.org/stable/c/e9d32ec26e7f01d1af13bdc687f586362546aa25 https://git.kernel.org/stable/c/563f23b002534176f49524b5ca0e1d94d8906c40 •