Page 8 of 3252 results (0.002 seconds)

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy() The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a metadata array to/from user space, may copy uninitialized buffer regions to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO and NILFS_IOCTL_GET_CPINFO. This can occur when the element size of the user space metadata given by the v_size member of the argument nilfs_argv structure is larger than the... • https://git.kernel.org/stable/c/a94932381e8dae4117e9129b3c1282e18aa97b05 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling Reset the eVMCS controls in the per-CPU VP assist page during hardware disabling instead of waiting until kvm-intel's module exit. The controls are activated if and only if KVM creates a VM, i.e. don't need to be reset if hardware is never enabled. Doing the reset during hardware disabling will naturally fix a potential NULL pointer deref bug once KVM disables CPU ho... • https://git.kernel.org/stable/c/afb26bfc01db6ef4728e96314f08431934ffe833 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes /dev/kvm to userspace and thus allows userspace to create VMs (and call other ioctls). E.g. KVM will encounter a NULL pointer when attempting to add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to create a VM before vmx_init() configures said list. BUG: kernel NULL pointer d... • https://git.kernel.org/stable/c/e136e969d268b9b89329c816c002e53f60e82985 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the c... • https://git.kernel.org/stable/c/76e3cc126bb223013a6b9a0e2a51238d1ef2e409 •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backt... • https://git.kernel.org/stable/c/abf79bb341bf52f75f295b850abdf5f78f584311 •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix WARNING in __ip_vs_cleanup_batch() During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn or ip_vs_conn_sync fails to be created, the initialization is successful by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't be found during the remove. The following is the stack information: name 'ip_vs_conn_sync' WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked i... • https://git.kernel.org/stable/c/61b1ab4583e275af216c8454b9256de680499b19 •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix WARNING in ip_vs_app_net_cleanup() During the initialization of ip_vs_app_net_init(), if file ip_vs_app fails to be created, the initialization is successful by default. Therefore, the ip_vs_app file doesn't be found during the remove in ip_vs_app_net_cleanup(). It will cause WRNING. The following is the stack information: name 'ip_vs_app' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked... • https://git.kernel.org/stable/c/457c4cbc5a3dde259d2a1f15d5f9785290397267 •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release(). In the Linux kernel, the fol... • https://git.kernel.org/stable/c/1fa5ae857bb14f6046205171d98506d8112dd74e •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the uno... • https://git.kernel.org/stable/c/3301958b7c1dae8f0f5ded63aa881e0b71e78464 •

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

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu Fix the race condition between the following two flows that run in parallel: 1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb. 2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram. An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2cap_reassemble_sdu can't use ... • https://git.kernel.org/stable/c/4b51dae96731c9d82f5634e75ac7ffd3b9c1b060 •