CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43877 – media: pci: ivtv: Add check for DMA map result
https://notcve.org/view.php?id=CVE-2024-43877
In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/1932dc2f4cf6ac23e48e5fcc24d21adbe35691d1 https://git.kernel.org/stable/c/24062aa7407091dee3e45a8e8037df437e848718 https://git.kernel.org/stable/c/3d8fd92939e21ff0d45100ab208f8124af79402a https://git.kernel.org/stable/c/c766065e8272085ea9c436414b7ddf1f12e7787b https://git.kernel.org/stable/c/629913d6d79508b166c66e07e4857e20233d85a9 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43876 – PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()
https://notcve.org/view.php?id=CVE-2024-43876
In the Linux kernel, the following vulnerability has been resolved: PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup() Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources. This makes an actual link issue less verbose. First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller. In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pm_test, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcar_pcie_wakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PM_ENTER_L1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit. Once rcar_pcie_wakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state. Reduce this warning verbosity. • https://git.kernel.org/stable/c/84b576146294c2be702cfcd174eaa74167e276f9 https://git.kernel.org/stable/c/2ae4769332dfdb97f4b6f5dc9ac8f46d02aaa3df https://git.kernel.org/stable/c/526a877c6273d4cd0d0aede84c1d620479764b1c https://git.kernel.org/stable/c/3ff3bdde950f1840df4030726cef156758a244d7 https://git.kernel.org/stable/c/c93637e6a4c4e1d0e85ef7efac78d066bbb24d96 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43875 – PCI: endpoint: Clean up error handling in vpci_scan_bus()
https://notcve.org/view.php?id=CVE-2024-43875
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure. • https://git.kernel.org/stable/c/e2b6ef72b7aea9d7d480d2df499bcd1c93247abb https://git.kernel.org/stable/c/e35f56bb03304abc92c928b641af41ca372966bb https://git.kernel.org/stable/c/24414c842a24d0fd498f9db6d2a762a8dddf1832 https://git.kernel.org/stable/c/7d368de78b60088ec9031c60c88976c0063ea4c0 https://git.kernel.org/stable/c/0e27e2e8697b8ce96cdef43f135426525d9d1f8f https://git.kernel.org/stable/c/b9e8695246bcfc028341470cbf92630cdc1ba36b https://git.kernel.org/stable/c/8e0f5a96c534f781e8c57ca30459448b3bfe5429 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43874 – crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked
https://notcve.org/view.php?id=CVE-2024-43874
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked Fix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE. Return from __sev_snp_shutdown_locked() if the psp_device or the sev_device structs are not initialized. Without the fix, the driver will produce the following splat: ccp 0000:55:00.5: enabling device (0000 -> 0002) ccp 0000:55:00.5: sev enabled ccp 0000:55:00.5: psp enabled BUG: kernel NULL pointer dereference, address: 00000000000000f0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29 RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0 R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x6f/0xb0 ? __die+0xcc/0xf0 ? page_fault_oops+0x330/0x3a0 ? • https://git.kernel.org/stable/c/1ca5614b84eed5904f65f143e0e7aaab0ac4c6b2 https://git.kernel.org/stable/c/bbf2c94503f6a421ed9b79e300d8085810da765d https://git.kernel.org/stable/c/468e3295774d0edce15f4ae475913b5076dd4f40 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43873 – vhost/vsock: always initialize seqpacket_allow
https://notcve.org/view.php?id=CVE-2024-43873
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features • https://git.kernel.org/stable/c/ced7b713711fdd8f99d8d04dc53451441d194c60 https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582 https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22 •