CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52787 – blk-mq: make sure active queue usage is held for bio_integrity_prep()
https://notcve.org/view.php?id=CVE-2023-52787
In the Linux kernel, the following vulnerability has been resolved: blk-mq: make sure active queue usage is held for bio_integrity_prep() blk_integrity_unregister() can come if queue usage counter isn't held for one bio with integrity prepared, so this request may be completed with calling profile->complete_fn, then kernel panic. Another constraint is that bio_integrity_prep() needs to be called before bio merge. Fix the issue by: - call bio_integrity_prep() with one queue usage counter grabbed reliably - call bio_integrity_prep() before bio merge En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: asegúrese de que el uso de la cola activa se mantenga para bio_integrity_prep() blk_integrity_unregister() puede aparecer si el contador de uso de la cola no se mantiene para una biografía con integridad preparada, por lo que esta solicitud se puede completar llamando al perfil->complete_fn, luego kernel panic. Otra restricción es que es necesario llamar a bio_integrity_prep() antes de la fusión biológica. Solucione el problema de la siguiente manera: - llame a bio_integrity_prep() con un contador de uso de cola capturado de manera confiable - llame a bio_integrity_prep() antes de fusionar la biografía • https://git.kernel.org/stable/c/900e080752025f0016128f07c9ed4c50eba3654b https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9 https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78 https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52786 – ext4: fix racy may inline data check in dio write
https://notcve.org/view.php?id=CVE-2023-52786
In the Linux kernel, the following vulnerability has been resolved: ext4: fix racy may inline data check in dio write syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below: if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data. The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds. The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige la verificación de datos en línea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmación a la que se hace referencia a continuación: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en línea. • https://git.kernel.org/stable/c/310ee0902b8d9d0a13a5a13e94688a5863fa29c2 https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52785 – scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR
https://notcve.org/view.php?id=CVE-2023-52785
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR If command timeout happens and cq complete IRQ is raised at the same time, ufshcd_mcq_abort clears lprb->cmd and a NULL pointer deref happens in the ISR. Error log: ufshcd_abort: Device abort task at tag 18 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 pc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: soluciona el problema de ejecuciones entre ufshcd_mcq_abort() e ISR. Si se agota el tiempo de espera del comando y se genera cq complete IRQ al mismo tiempo, ufshcd_mcq_abort borra lprb->cmd y un La eliminación del puntero NULL ocurre en el ISR. Registro de errores: ufshcd_abort: tarea de cancelación del dispositivo en la etiqueta 18 No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000108 pc: [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr: [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24 /0x114 • https://git.kernel.org/stable/c/f1304d4420777f82a1d844c606db3d9eca841765 https://git.kernel.org/stable/c/8f15a7e3c054d960bbd1521110700450bbf798a1 https://git.kernel.org/stable/c/f84d461f33a6b27304d468d9cfb56c0cefdb4ee7 https://git.kernel.org/stable/c/27900d7119c464b43cd9eac69c85884d17bae240 •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52784 – bonding: stop the device in bond_setup_by_slave()
https://notcve.org/view.php?id=CVE-2023-52784
In the Linux kernel, the following vulnerability has been resolved: bonding: stop the device in bond_setup_by_slave() Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today. In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type. The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed. A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: detener el dispositivo en bond_setup_by_slave(). El compromiso 9eed321cde22 ("net: lapbether: solo admite dispositivos ethernet") ha podido mantener a syzbot alejado de net/lapb, hasta hoy. En el siguiente símbolo [1], el problema es que se ha creado un dispositivo lapbether sobre un dispositivo de unión sin miembros. • https://git.kernel.org/stable/c/872254dd6b1f80cb95ee9e2e22980888533fc293 https://git.kernel.org/stable/c/b4f0e605a508f6d7cda6df2f03a0c676b778b1fe https://git.kernel.org/stable/c/396baca6683f415b5bc2b380289387bef1406edc https://git.kernel.org/stable/c/53064e8239dd2ecfefc5634e991f1025abc2ee0c https://git.kernel.org/stable/c/19554aa901b5833787df4417a05ccdebf351b7f4 https://git.kernel.org/stable/c/87c49806a37f88eddde3f537c162fd0c2834170c https://git.kernel.org/stable/c/d98c91215a5748a0f536e7ccea26027005196859 https://git.kernel.org/stable/c/3cffa2ddc4d3fcf70cde361236f5a614f • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52783 – net: wangxun: fix kernel panic due to null pointer
https://notcve.org/view.php?id=CVE-2023-52783
In the Linux kernel, the following vulnerability has been resolved: net: wangxun: fix kernel panic due to null pointer When the device uses a custom subsystem vendor ID, the function wx_sw_init() returns before the memory of 'wx->mac_table' is allocated. The null pointer will causes the kernel panic. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wangxun: corrige el pánico del kernel debido a un puntero null. Cuando el dispositivo utiliza un ID de proveedor de subsistema personalizado, la función wx_sw_init() regresa antes de que se agote la memoria de 'wx->mac_table'. asignado. El puntero null provocará el pánico en el kernel. • https://git.kernel.org/stable/c/79625f45ca73ef37c18a6e4b5b6ce7daa1e92683 https://git.kernel.org/stable/c/61a55071653974dab172d4c5d699bb365cfd13c9 https://git.kernel.org/stable/c/8ba2c459668cfe2aaacc5ebcd35b4b9ef8643013 • CWE-476: NULL Pointer Dereference •