Page 233 of 3073 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Co ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: rp2: use 'request_firmware' en lugar de 'request_firmware_nowait' En 'rp2_probe', el controlador registra 'rp2_uart_interrupt' y luego llama a 'rp2_fw_cb' a través de 'request_firmware_nowait'. En 'rp2_fw_cb', si el firmware no existe, la función simplemente regresa sin inicializar los puertos de 'rp2_card'. Pero ahora la función de manejo de interrupciones ha sido registrada, y cuando llega una interrupción, 'rp2_uart_interrupt' puede acceder a esos puertos y causar desreferencia al puntero NULL u otros errores. • https://git.kernel.org/stable/c/1e04d5d5fe5e76af68f834e1941fcbfa439653be https://git.kernel.org/stable/c/c697244ce940ec07e2d745ccb63ca97fc0266fbc https://git.kernel.org/stable/c/1cc57cb32c84e059bd158494f746b665fc14d1b1 https://git.kernel.org/stable/c/35265552c7fe9553c75e324c80f45e28ff14eb6e https://git.kernel.org/stable/c/915452f40e2f495e187276c4407a4f567ec2307e https://git.kernel.org/stable/c/6a931ceb0b9401fe18d0c500e08164bf9cc7be4b https://git.kernel.org/stable/c/9b07b6973f7359e2dd6a9fe6db0c142634c823b7 https://git.kernel.org/stable/c/016002848c82eeb5d460489ce392d91fe •

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

In the Linux kernel, the following vulnerability has been resolved: NFS: fix an incorrect limit in filelayout_decode_layout() The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: corrige un límite incorrecto en filelayout_decode_layout() El "sizeof(struct nfs_fh)" es dos bytes demasiado grande y podría provocar daños en la memoria. Debería ser NFS_MAXFHSIZE porque ese es el tamaño del búfer -&gt;datos[]. Invertí el tamaño de los argumentos para poner la variable a la izquierda. • https://git.kernel.org/stable/c/16b374ca439fb406e46e071f75428f5b033056f8 https://git.kernel.org/stable/c/9d280ab53df1d4a1043bd7a9e7c6a2f9cfbfe040 https://git.kernel.org/stable/c/b287521e9e94bb342ebe5fd8c3fd7db9aef4e6f1 https://git.kernel.org/stable/c/f299522eda1566cbfbae4b15c82970fc41b03714 https://git.kernel.org/stable/c/945ebef997227ca8c20bad7f8a8358c8ee57a84a https://git.kernel.org/stable/c/e411df81cd862ef3d5b878120b2a2fef0ca9cdb1 https://git.kernel.org/stable/c/9b367fe770b1b80d7bf64ed0d177544a44405f6e https://git.kernel.org/stable/c/d34fb628f6ef522f996205a9e578216bb •

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

In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot: https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug? • https://git.kernel.org/stable/c/636752bcb5177a301d0266270661581de8624828 https://git.kernel.org/stable/c/f9469082126cebb7337db3992d143f5e4edfe629 https://git.kernel.org/stable/c/09c9e79f4c10cfb6b9e0e1b4dd355232e4b5a3b3 https://git.kernel.org/stable/c/dfa8929e117b0228a7765f5c3f5988a4a028f3c6 https://git.kernel.org/stable/c/c70e1ba2e7e65255a0ce004f531dd90dada97a8c https://git.kernel.org/stable/c/04cc05e3716ae31b17ecdab7bc55c8170def1b8b https://git.kernel.org/stable/c/b523feb7e8e44652f92f3babb953a976e7ccbbef https://git.kernel.org/stable/c/1f583d3813f204449037cd2acbfc09168 • CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: net: fujitsu: fix potential null-ptr-deref In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fujitsu: corrige el potencial null-ptr-deref En fmvj18x_get_hwinfo(), si ioremap falla, habrá un puntero NULL deref. Para solucionar este problema, verifique el valor de retorno de ioremap y devuelva -1 a la persona que llama en caso de falla. • https://git.kernel.org/stable/c/b92170e209f7746ed72eaac98f2c2f4b9af734e6 https://git.kernel.org/stable/c/6dbf1101594f7c76990b63c35b5a40205a914b6b https://git.kernel.org/stable/c/c4f1c23edbe921ab2ecd6140d700e756cd44c5f7 https://git.kernel.org/stable/c/7883d3895d0fbb0ba9bff0f8665f99974b45210f https://git.kernel.org/stable/c/22049c3d40f08facd1867548716a484dad6b3251 https://git.kernel.org/stable/c/71723a796ab7881f491d663c6cd94b29be5fba50 https://git.kernel.org/stable/c/f14bf57a08779a5dee9936f63ada0149ea89c5e6 https://git.kernel.org/stable/c/52202be1cd996cde6e8969a128dc27ee4 •

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

In the Linux kernel, the following vulnerability has been resolved: mld: fix panic in mld_newpack() mld_newpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom size is too large, a kernel panic could occur in skb_put(). Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up done Splat looks like: kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP: 0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000 RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028 R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000) GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? • https://git.kernel.org/stable/c/72e09ad107e78d69ff4d3b97a69f0aad2b77280f https://git.kernel.org/stable/c/0e35b7457b7b6e73ffeaaca1a577fdf1af0feca1 https://git.kernel.org/stable/c/17728616a4c85baf0edc975c60ba4e4157684d9a https://git.kernel.org/stable/c/221142038f36d9f28b64e83e954774da4d4ccd17 https://git.kernel.org/stable/c/4b77ad9097067b31237eeeee0bf70f80849680a0 https://git.kernel.org/stable/c/37d697759958d111439080bab7e14d2b0e7b39f5 https://git.kernel.org/stable/c/beb39adb150f8f3b516ddf7c39835a9788704d23 https://git.kernel.org/stable/c/a76fb9ba545289379acf409653ad5f744 •