Page 4 of 5519 results (0.020 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: x86/xen: don't do PV iret hypercall through hypercall page Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S. This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations. This is part of XSA-466 / CVE-2024-53241. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/xen: no realizar la hiperllamada de PV iret a través de la página de hiperllamada En lugar de saltar a la página de hiperllamada de Xen para realizar la hiperllamada iret, codificar directamente la secuencia requerida en xen-asm.S. Esto se hace como preparación para no utilizar más la página de hiperllamada, ya que se ha demostrado que causa problemas con las mitigaciones de especulación. Esto es parte de XSA-466 / CVE-2024-53241. • https://git.kernel.org/stable/c/05df6e6cd9a76b778aee33c3c18c9f3b3566d4a5 https://git.kernel.org/stable/c/c7b4cfa6213a44fa48714186dfdf125072d036e3 https://git.kernel.org/stable/c/fa719857f613fed94a79da055b13ca51214c694f https://git.kernel.org/stable/c/82c211ead1ec440dbf81727e17b03b5e3c44b93d https://git.kernel.org/stable/c/f7c3fdad0a474062d566aae3289d490d7e702d30 https://git.kernel.org/stable/c/a2796dff62d6c6bfc5fbebdf2bee0d5ac0438906 http://www.openwall.com/lists/oss-security/2024/12/17/2 http://www.openwall.com/lists/oss-security/2024/12 •

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

In the Linux kernel, the following vulnerability has been resolved: xen/netfront: fix crash when removing device When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time. Fix that by checking the queues are existing before trying to stop them. This is XSA-465 / CVE-2024-53240. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/netfront: se corrige un fallo al eliminar un dispositivo Al eliminar un dispositivo netfront directamente después de un ciclo de suspensión/reanudación, puede suceder que las colas no se hayan configurado nuevamente, lo que provoca un fallo durante el intento de detener las colas otra vez. Solucione esto comprobando que las colas existen antes de intentar detenerlas. Esto es XSA-465 / CVE-2024-53240. • https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050 https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9 https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84 https://git.kernel.org/stable/c/20f7f0cf7af5d81b218202ef504223af84b16a8f https://git.kernel.org/stable/c/1d5354a9182b6d302ae10367cbec1ca33 •

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

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: 0

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: 0

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 •