Page 133 of 2832 results (0.009 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them a... • https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop ... • https://git.kernel.org/stable/c/68866e425be2ef2664aa5c691bb3ab789736acf5 • CWE-20: Improper Input Validation CWE-129: Improper Validation of Array Index •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however... • https://git.kernel.org/stable/c/f67055780caac6a99f43834795c43acf99eba6a6 •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_mod... • https://git.kernel.org/stable/c/a42d985bd5b234da8b61347a78dc3057bf7bb94d • CWE-476: NULL Pointer Dereference •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after ... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 • CWE-122: Heap-based Buffer Overflow •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6... • https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555 •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una co... • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 • CWE-833: Deadlock •

CVSS: 4.6EPSS: 0%CPEs: 7EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the va... • https://git.kernel.org/stable/c/9772b47a4c2916d645c551228b6085ea24acbe5d •

CVSS: 9.8EPSS: 0%CPEs: 4EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash ... • https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the prealloca... • https://git.kernel.org/stable/c/fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a • CWE-415: Double Free •