Page 207 of 3881 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

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: 0

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: 0

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 •

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. • https://git.kernel.org/stable/c/a5073d6054f75d7c94b3354206eec4b804d2fbd4 https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08 https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b •

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

In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). • https://git.kernel.org/stable/c/ff86aae3b4112b85d2231c23bccbc49589df1c06 https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85 https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85 https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96 https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701 https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •