CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-53144 – Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
https://notcve.org/view.php?id=CVE-2024-53144
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing). CVE: CVE-2024-8805 • https://git.kernel.org/stable/c/ba15a58b179ed76a7e887177f2b06de12c58ec8f https://git.kernel.org/stable/c/373d1dfcffc63c68184419264a7eaed422c7958e https://git.kernel.org/stable/c/bc96ff59b2f19e924d9e15e24cee19723d674b92 https://git.kernel.org/stable/c/6ab84785311dc4d0348e6bd4e1c491293b770b98 https://git.kernel.org/stable/c/778763287ded64dd5c022435d3e0e3182f148a64 https://git.kernel.org/stable/c/9a5fcacabde0fe11456f4a1e88072c01846cea25 https://git.kernel.org/stable/c/039da39a616103ec7ab8ac351bfb317854e5507c https://git.kernel.org/stable/c/d17c631ba04e960eb6f8728b10d585de2 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53142 – initramfs: avoid filename buffer overrun
https://notcve.org/view.php?id=CVE-2024-53142
In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/bb7ac96670ab1d8d681015f9d66e45dad579af4d https://git.kernel.org/stable/c/c509b1acbd867d9e09580fe059a924cb5825afb1 https://git.kernel.org/stable/c/d3df9f26cff97beaa5643e551031795d5d5cddbe https://git.kernel.org/stable/c/6983b8ac787b3add5571cda563574932a59a99bb https://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8 https://git.kernel.org/stable/c/1a423bbbeaf9e3e20c4686501efd9b661fe834db https://git.kernel.org/stable/c/49d01e736c3045319e030d1e75fb98301 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53141 – netfilter: ipset: add missing range check in bitmap_ip_uadt
https://notcve.org/view.php?id=CVE-2024-53141
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. • https://git.kernel.org/stable/c/72205fc68bd13109576aa6c4c12c740962d28a6c https://git.kernel.org/stable/c/3c20b5948f119ae61ee35ad8584d666020c91581 https://git.kernel.org/stable/c/78b0f2028f1043227a8eb0c41944027fc6a04596 https://git.kernel.org/stable/c/2e151b8ca31607d14fddc4ad0f14da0893e1a7c7 https://git.kernel.org/stable/c/e67471437ae9083fa73fa67eee1573fec1b7c8cf https://git.kernel.org/stable/c/7ffef5e5d5eeecd9687204a5ec2d863752aafb7e https://git.kernel.org/stable/c/856023ef032d824309abd5c747241dffa33aae8c https://git.kernel.org/stable/c/591efa494a1cf649f50a35def649c43ae •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-53140 – netlink: terminate outstanding dump on socket close
https://notcve.org/view.php?id=CVE-2024-53140
In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. • https://git.kernel.org/stable/c/ed5d7788a934a4b6d6d025e948ed4da496b4f12e https://git.kernel.org/stable/c/baaf0c65bc8ea9c7a404b09bc8cc3b8a1e4f18df https://git.kernel.org/stable/c/25d9b4bb64ea964769087fc5ae09aee9c838d759 https://git.kernel.org/stable/c/114a61d8d94ae3a43b82446cf737fd757021b834 https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559 https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4 https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603 https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53138 – net/mlx5e: kTLS, Fix incorrect page refcounting
https://notcve.org/view.php?id=CVE-2024-53138
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: kTLS, Fix wrong page refcounting El código de manejo de tx de kTLS usa una combinación de API get_page() y page_ref_inc() para incrementar la referencia de página. Pero en la ruta de lanzamiento (mlx5e_ktls_tx_handle_resync_dump_comp()), solo se usa put_page(). • https://git.kernel.org/stable/c/84d1bb2b139e0184b1754aa1b5776186b475fce8 https://git.kernel.org/stable/c/a0ddb20a748b122ea86003485f7992fa5e84cc95 https://git.kernel.org/stable/c/ffad2ac8c859c1c1a981fe9c4f7ff925db684a43 https://git.kernel.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf115c297839d https://git.kernel.org/stable/c/93a14620b97c911489a5b008782f3d9b0c4aeff4 https://git.kernel.org/stable/c/2723e8b2cbd486cb96e5a61b22473f7fd62e18df https://git.kernel.org/stable/c/dd6e972cc5890d91d6749bb48e3912721 •