Page 97 of 3061 results (0.018 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic. • https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419 https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799 https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62 https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0 https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9 https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd •

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

In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. • https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7 https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916 https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44 https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701 https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 https://access.redhat.com/security/cve/CVE-2024-40967 https://bugzilla.redhat.com/show_bug.cgi?id=2297551 • CWE-833: Deadlock •

CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tty: add the option to have a tty reject a new ldisc ... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on. This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659 when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock. • https://git.kernel.org/stable/c/3c6332f3bb1578b5b10ac2561247b1d6272ae937 https://git.kernel.org/stable/c/287b569a5b914903ba7c438a3c0dbc3410ebb409 https://git.kernel.org/stable/c/5920ac19964f9e20181f63b410d9200ddbf8dc86 https://git.kernel.org/stable/c/6bd23e0c2bb6c65d4f5754d1456bc9a4427fc59b https://access.redhat.com/security/cve/CVE-2024-40966 https://bugzilla.redhat.com/show_bug.cgi?id=2297550 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well. A vulnerability was found in the lpi2c driver in the Linux kernel's i2c subsystem, where the clk_get_rate function is called during data transfers, which can lead to a deadlock situation when an audio codec attempts to access the i2c bus while holding the clock mutex, resulting in a denial of service. • https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a https://access.redhat.com/security/cve/CVE-2024-40965 https://bugzilla.redhat.com/show_bug.cgi?id=2297549 • CWE-833: Deadlock •

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

In the Linux kernel, the following vulnerability has been resolved: xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr() ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7 https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3 https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1 https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08 https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41 https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333 • CWE-476: NULL Pointer Dereference •