CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46968 – s390/zcrypt: fix zcard and zqueue hot-unplug memleak
https://notcve.org/view.php?id=CVE-2021-46968
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix zcard and zqueue hot-unplug memleak Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige zcard y zqueue hot-unplug memleak Las pruebas con kvm y un kernel kmemdebug mostraron que, al desconectar en caliente, las estructuras zcard y zqueue para la tarjeta o cola desconectada no están liberado correctamente debido a una discrepancia con get/put para el contador kref integrado. Esta solución ahora ajusta el manejo de los contadores kref. • https://git.kernel.org/stable/c/29c2680fd2bf3862ff5cf2957f198512493156f9 https://git.kernel.org/stable/c/026499a9c2e002e621ad568d1378324ae97e5524 https://git.kernel.org/stable/c/055a063a18bcd19b93709e3eac8078d6b2f04599 https://git.kernel.org/stable/c/971dc8706cee47393d393905d294ea47e39503d3 https://git.kernel.org/stable/c/70fac8088cfad9f3b379c9082832b4d7532c16c2 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46967 – vhost-vdpa: fix vm_flags for virtqueue doorbell mapping
https://notcve.org/view.php?id=CVE-2021-46967
In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vhost-vdpa: corrige vm_flags para el mapeo del timbre virtqueue El timbre virtqueue generalmente se implementa a través de registros, pero no proporcionamos los vma->flags necesarios como VM_PFNMAP. • https://git.kernel.org/stable/c/ddd89d0a059d8e9740c75a97e0efe9bf07ee51f9 https://git.kernel.org/stable/c/3b8b6399666a29daa30b0bb3f5c9e3fc81c5a6a6 https://git.kernel.org/stable/c/940230a5c31e2714722aee04c521a21f484b4df7 https://git.kernel.org/stable/c/93dbbf20e3ffad14f04227a0b7105f6e6f0387ce https://git.kernel.org/stable/c/3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46966 – ACPI: custom_method: fix potential use-after-free issue
https://notcve.org/view.php?id=CVE-2021-46966
In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función. • https://git.kernel.org/stable/c/4bda2b79a9d04c8ba31681c66e95877dbb433416 https://git.kernel.org/stable/c/5c12dadcbef8cd55ef1f5dac799bfcbb7ea7db1d https://git.kernel.org/stable/c/35b88a10535edcf62d3e6b7893a8cd506ff98a24 https://git.kernel.org/stable/c/e4467fb6ef547aa352dc03397f9474ec84eced5b https://git.kernel.org/stable/c/03d1571d9513369c17e6848476763ebbd10ec2cb https://git.kernel.org/stable/c/70424999fbf1f160ade111cb9baab51776e0f9c2 https://git.kernel.org/stable/c/06cd4a06eb596a888239fb8ceb6ea15677cab396 https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46965 – mtd: physmap: physmap-bt1-rom: Fix unintentional stack access
https://notcve.org/view.php?id=CVE-2021-46965
In the Linux kernel, the following vulnerability has been resolved: mtd: physmap: physmap-bt1-rom: Fix unintentional stack access Cast &data to (char *) in order to avoid unintentionally accessing the stack. Notice that data is of type u32, so any increment to &data will be in the order of 4-byte chunks, and this piece of code is actually intended to be a byte offset. Addresses-Coverity-ID: 1497765 ("Out-of-bounds access") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: physmap: physmap-bt1-rom: corrige el acceso involuntario a la pila. Transmite &data a (char *) para evitar el acceso involuntario a la pila. Tenga en cuenta que los datos son de tipo u32, por lo que cualquier incremento en &data será del orden de fragmentos de 4 bytes, y este fragmento de código en realidad está destinado a ser un desplazamiento de bytes. Direcciones-Coverity-ID: 1497765 ("Acceso fuera de límites") • https://git.kernel.org/stable/c/b3e79e7682e075326df8041b826b03453acacd0a https://git.kernel.org/stable/c/34ec706bf0b7c4ca249a729c1bcb91f706c7a7be https://git.kernel.org/stable/c/4e4ebb827bf09311469ffd9d0c14ed40ed9747aa https://git.kernel.org/stable/c/4d786870e3262ec098a3b4ed10b895176bc66ecb https://git.kernel.org/stable/c/683313993dbe1651c7aa00bb42a041d70e914925 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46964 – scsi: qla2xxx: Reserve extra IRQ vectors
https://notcve.org/view.php?id=CVE-2021-46964
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reserve extra IRQ vectors Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? • https://git.kernel.org/stable/c/a6dcfe08487e5e83b6b4214c959a9577a9ed2d9f https://git.kernel.org/stable/c/4ecd42dec858b6632c5f024fe13e9ad6c30f2734 https://git.kernel.org/stable/c/0f86d66b38501e3ac66cf2d9f9f8ad6838bad0e6 https://git.kernel.org/stable/c/f02d4086a8f36a0e1aaebf559b54cf24a177a486 •