Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: associate skb with a device at tx<br /> <br /> Syzkaller triggered flow dissector warning with the following:<br /> <br /> r0 = openat$ppp(0xffffffffffffff9c, &amp;(0x7f0000000000), 0xc0802, 0x0)<br /> ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &amp;(0x7f00000000c0))<br /> ioctl$PPPIOCSACTIVE(r0, 0x40107446, &amp;(0x7f0000000240)={0x2, &amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})<br /> pwritev(r0, &amp;(0x7f0000000040)=[{&amp;(0x7f0000000140)=&amp;#39;\x00!&amp;#39;, 0x2}], 0x1, 0x0, 0x0)<br /> <br /> [ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0<br /> [ 9.485929] skb_get_poff+0x53/0xa0<br /> [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20<br /> [ 9.485944] ? ppp_send_frame+0xc2/0x5b0<br /> [ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60<br /> [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0<br /> [ 9.485968] ? ppp_xmit_process+0x5b/0xb0<br /> [ 9.485974] ? ppp_write+0x12a/0x190<br /> [ 9.485981] ? do_iter_write+0x18e/0x2d0<br /> [ 9.485987] ? __import_iovec+0x30/0x130<br /> [ 9.485997] ? do_pwritev+0x1b6/0x240<br /> [ 9.486016] ? trace_hardirqs_on+0x47/0x50<br /> [ 9.486023] ? __x64_sys_pwritev+0x24/0x30<br /> [ 9.486026] ? do_syscall_64+0x3d/0x80<br /> [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Flow dissector tries to find skb net namespace either via device<br /> or via socket. Neigher is set in ppp_send_frame, so let&amp;#39;s manually<br /> use ppp-&gt;dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio: uio_dmem_genirq: Fix missing unlock in irq configuration<br /> <br /> Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in<br /> uio_dmem_genirq_irqcontrol()") started calling disable_irq() without<br /> holding the spinlock because it can sleep. However, that fix introduced<br /> another bug: if interrupt is already disabled and a new disable request<br /> comes in, then the spinlock is not unlocked:<br /> <br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002<br /> [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc]<br /> [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21<br /> [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 14.855664] Call Trace:<br /> [ 14.855861] <br /> [ 14.856025] dump_stack_lvl+0x4d/0x67<br /> [ 14.856325] dump_stack+0x14/0x1a<br /> [ 14.856583] __schedule_bug.cold+0x4b/0x5c<br /> [ 14.856915] __schedule+0xe81/0x13d0<br /> [ 14.857199] ? idr_find+0x13/0x20<br /> [ 14.857456] ? get_work_pool+0x2d/0x50<br /> [ 14.857756] ? __flush_work+0x233/0x280<br /> [ 14.858068] ? __schedule+0xa95/0x13d0<br /> [ 14.858307] ? idr_find+0x13/0x20<br /> [ 14.858519] ? get_work_pool+0x2d/0x50<br /> [ 14.858798] schedule+0x6c/0x100<br /> [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110<br /> [ 14.859335] ? tty_write_room+0x1f/0x30<br /> [ 14.859598] ? n_tty_poll+0x1ec/0x220<br /> [ 14.859830] ? tty_ldisc_deref+0x1a/0x20<br /> [ 14.860090] schedule_hrtimeout_range+0x17/0x20<br /> [ 14.860373] do_select+0x596/0x840<br /> [ 14.860627] ? __kernel_text_address+0x16/0x50<br /> [ 14.860954] ? poll_freewait+0xb0/0xb0<br /> [ 14.861235] ? poll_freewait+0xb0/0xb0<br /> [ 14.861517] ? rpm_resume+0x49d/0x780<br /> [ 14.861798] ? common_interrupt+0x59/0xa0<br /> [ 14.862127] ? asm_common_interrupt+0x2b/0x40<br /> [ 14.862511] ? __uart_start.isra.0+0x61/0x70<br /> [ 14.862902] ? __check_object_size+0x61/0x280<br /> [ 14.863255] core_sys_select+0x1c6/0x400<br /> [ 14.863575] ? vfs_write+0x1c9/0x3d0<br /> [ 14.863853] ? vfs_write+0x1c9/0x3d0<br /> [ 14.864121] ? _copy_from_user+0x45/0x70<br /> [ 14.864526] do_pselect.constprop.0+0xb3/0xf0<br /> [ 14.864893] ? do_syscall_64+0x6d/0x90<br /> [ 14.865228] ? do_syscall_64+0x6d/0x90<br /> [ 14.865556] __x64_sys_pselect6+0x76/0xa0<br /> [ 14.865906] do_syscall_64+0x60/0x90<br /> [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50<br /> [ 14.866640] ? do_syscall_64+0x6d/0x90<br /> [ 14.866972] ? do_syscall_64+0x6d/0x90<br /> [ 14.867286] ? do_syscall_64+0x6d/0x90<br /> [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...] stripped<br /> [ 14.872959] <br /> <br /> (&amp;#39;myfpga&amp;#39; is a simple &amp;#39;uio_dmem_genirq&amp;#39; driver I wrote to test this)<br /> <br /> The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and<br /> it is used in a similar manner to the "uio_pdrv_genirq" driver with respect<br /> to interrupt configuration and handling. At the time "uio_dmem_genirq" was<br /> introduced, both had the same implementation of the &amp;#39;uio_info&amp;#39; handlers<br /> irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency<br /> issue"), which was only applied to "uio_pdrv_genirq", ended up making them<br /> a little different. That commit, among other things, changed disable_irq()<br /> to disable_irq_nosync() in the implementation of irqcontrol(). The<br /> motivation there was to avoid a deadlock between irqcontrol() and<br /> handler(), since it added a spinlock in the irq handler, and disable_irq()<br /> waits for the completion of the irq handler.<br /> <br /> By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also<br /> avoid the sleeping-whil<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: atmel-mci: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> So fix this by checking the return value and calling mmc_free_host()<br /> in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix panic due to wrong pageattr of im-&gt;image<br /> <br /> In the scenario where livepatch and kretfunc coexist, the pageattr of<br /> im-&gt;image is rox after arch_prepare_bpf_trampoline in<br /> bpf_trampoline_update, and then modify_fentry or register_fentry returns<br /> -EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag<br /> will be configured, and arch_prepare_bpf_trampoline will be re-executed.<br /> <br /> At this time, because the pageattr of im-&gt;image is rox,<br /> arch_prepare_bpf_trampoline will read and write im-&gt;image, which causes<br /> a fault. as follows:<br /> <br /> insmod livepatch-sample.ko # samples/livepatch/livepatch-sample.c<br /> bpftrace -e &amp;#39;kretfunc:cmdline_proc_show {}&amp;#39;<br /> <br /> BUG: unable to handle page fault for address: ffffffffa0206000<br /> PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061<br /> Oops: 0003 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 270 Comm: bpftrace Tainted: G E K 6.1.0 #5<br /> RIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0<br /> RSP: 0018:ffffc90001083ad8 EFLAGS: 00010202<br /> RAX: ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000<br /> RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030<br /> RBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400<br /> R10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8<br /> R13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10<br /> FS: 00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bpf_trampoline_update+0x25a/0x6b0<br /> __bpf_trampoline_link_prog+0x101/0x240<br /> bpf_trampoline_link_prog+0x2d/0x50<br /> bpf_tracing_prog_attach+0x24c/0x530<br /> bpf_raw_tp_link_attach+0x73/0x1d0<br /> __sys_bpf+0x100e/0x2570<br /> __x64_sys_bpf+0x1c/0x30<br /> do_syscall_64+0x5b/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> With this patch, when modify_fentry or register_fentry returns -EAGAIN<br /> from bpf_tramp_ftrace_ops_func, the pageattr of im-&gt;image will be reset<br /> to nx+rw.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: Clear nfc_target before being used<br /> <br /> Fix a slab-out-of-bounds read that occurs in nla_put() called from<br /> nfc_genl_send_target() when target-&gt;sensb_res_len, which is duplicated<br /> from an nfc_target in pn533, is too large as the nfc_target is not<br /> properly initialized and retains garbage values. Clear nfc_targets with<br /> memset() before they are used.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nla_put<br /> Call Trace:<br /> memcpy<br /> nla_put<br /> nfc_genl_dump_targets<br /> genl_lock_dumpit<br /> netlink_dump<br /> __netlink_dump_start<br /> genl_family_rcv_msg_dumpit<br /> genl_rcv_msg<br /> netlink_rcv_skb<br /> genl_rcv<br /> netlink_unicast<br /> netlink_sendmsg<br /> sock_sendmsg<br /> ____sys_sendmsg<br /> ___sys_sendmsg<br /> __sys_sendmsg<br /> do_syscall_64

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: kill hooked chains to avoid loops on deduplicated compressed images<br /> <br /> After heavily stressing EROFS with several images which include a<br /> hand-crafted image of repeated patterns for more than 46 days, I found<br /> two chains could be linked with each other almost simultaneously and<br /> form a loop so that the entire loop won&amp;#39;t be submitted. As a<br /> consequence, the corresponding file pages will remain locked forever.<br /> <br /> It can be _only_ observed on data-deduplicated compressed images.<br /> For example, consider two chains with five pclusters in total:<br /> Chain 1: 2-&gt;3-&gt;4-&gt;5 -- The tail pcluster is 5;<br /> Chain 2: 5-&gt;1-&gt;2 -- The tail pcluster is 2.<br /> <br /> Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link<br /> to Chain 2 at the same time with pcluster 2.<br /> <br /> Since hooked chains are all linked locklessly now, I have no idea how<br /> to simply avoid the race. Instead, let&amp;#39;s avoid hooked chains completely<br /> until I could work out a proper way to fix this and end users finally<br /> tell us that it&amp;#39;s needed to add it back.<br /> <br /> Actually, this optimization can be found with multi-threaded workloads<br /> (especially even more often on deduplicated compressed images), yet I&amp;#39;m<br /> not sure about the overall system impacts of not having this compared<br /> with implementation complexity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Clean up integer overflow checking in map_user_pages()<br /> <br /> The encode_dma() function has some validation on in_trans-&gt;size but it<br /> would be more clear to move those checks to find_and_map_user_pages().<br /> <br /> The encode_dma() had two checks:<br /> <br /> if (in_trans-&gt;addr + in_trans-&gt;size addr || !in_trans-&gt;size)<br /> return -EINVAL;<br /> <br /> The in_trans-&gt;addr variable is the starting address. The in_trans-&gt;size<br /> variable is the total size of the transfer. The transfer can occur in<br /> parts and the resources-&gt;xferred_dma_size tracks how many bytes we have<br /> already transferred.<br /> <br /> This patch introduces a new variable "remaining" which represents the<br /> amount we want to transfer (in_trans-&gt;size) minus the amount we have<br /> already transferred (resources-&gt;xferred_dma_size).<br /> <br /> I have modified the check for if in_trans-&gt;size is zero to instead check<br /> if in_trans-&gt;size is less than resources-&gt;xferred_dma_size. If we have<br /> already transferred more bytes than in_trans-&gt;size then there are negative<br /> bytes remaining which doesn&amp;#39;t make sense. If there are zero bytes<br /> remaining to be copied, just return success.<br /> <br /> The check in encode_dma() checked that "addr + size" could not overflow<br /> and barring a driver bug that should work, but it&amp;#39;s easier to check if<br /> we do this in parts. First check that "in_trans-&gt;addr +<br /> resources-&gt;xferred_dma_size" is safe. Then check that "xfer_start_addr +<br /> remaining" is safe.<br /> <br /> My final concern was that we are dealing with u64 values but on 32bit<br /> systems the kmalloc() function will truncate the sizes to 32 bits. So<br /> I calculated "total = in_trans-&gt;size + offset_in_page(xfer_start_addr);"<br /> and returned -EINVAL if it were &gt;= SIZE_MAX. This will not affect 64bit<br /> systems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it returns<br /> a PCI device with refcount incremented, so it doesn&amp;#39;t need to<br /> call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI<br /> device needs to be put in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hpsa: Fix possible memory leak in hpsa_init_one()<br /> <br /> The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in<br /> hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to<br /> clean1 directly, which frees h and leaks the h-&gt;reply_map.<br /> <br /> Fix by calling hpda_free_ctlr_info() to release h-&gt;replay_map and h instead<br /> free h directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: Make port I/O string accessors actually work<br /> <br /> Fix port I/O string accessors such as `insb&amp;#39;, `outsb&amp;#39;, etc. which use<br /> the physical PCI port I/O address rather than the corresponding memory<br /> mapping to get at the requested location, which in turn breaks at least<br /> accesses made by our parport driver to a PCIe parallel port such as:<br /> <br /> PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20<br /> parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]<br /> <br /> causing a memory access fault:<br /> <br /> Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008<br /> Oops [#1]<br /> Modules linked in:<br /> CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23<br /> Hardware name: SiFive HiFive Unmatched A00 (DT)<br /> epc : parport_pc_fifo_write_block_pio+0x266/0x416<br /> ra : parport_pc_fifo_write_block_pio+0xb4/0x416<br /> epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60<br /> gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000<br /> t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0<br /> s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000<br /> a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb<br /> a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000<br /> s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50<br /> s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000<br /> s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000<br /> s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930<br /> t5 : 0000000000001000 t6 : 0000000000040000<br /> status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f<br /> [] parport_pc_compat_write_block_pio+0xfe/0x200<br /> [] parport_write+0x46/0xf8<br /> [] lp_write+0x158/0x2d2<br /> [] vfs_write+0x8e/0x2c2<br /> [] ksys_write+0x52/0xc2<br /> [] sys_write+0xe/0x16<br /> [] ret_from_syscall+0x0/0x2<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> For simplicity address the problem by adding PCI_IOBASE to the physical<br /> address requested in the respective wrapper macros only, observing that<br /> the raw accessors such as `__insb&amp;#39;, `__outsb&amp;#39;, etc. are not supposed to<br /> be used other than by said macros. Remove the cast to `long&amp;#39; that is no<br /> longer needed on `addr&amp;#39; now that it is used as an offset from PCI_IOBASE<br /> and add parentheses around `addr&amp;#39; needed for predictable evaluation in<br /> macro expansion. No need to make said adjustments in separate changes<br /> given that current code is gravely broken and does not ever work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix recursive locking direct_mutex in ftrace_modify_direct_caller<br /> <br /> Naveen reported recursive locking of direct_mutex with sample<br /> ftrace-direct-modify.ko:<br /> <br /> [ 74.762406] WARNING: possible recursive locking detected<br /> [ 74.762887] 6.0.0-rc6+ #33 Not tainted<br /> [ 74.763216] --------------------------------------------<br /> [ 74.763672] event-sample-fn/1084 is trying to acquire lock:<br /> [ 74.764152] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> register_ftrace_function+0x1f/0x180<br /> [ 74.764922]<br /> [ 74.764922] but task is already holding lock:<br /> [ 74.765421] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.766142]<br /> [ 74.766142] other info that might help us debug this:<br /> [ 74.766701] Possible unsafe locking scenario:<br /> [ 74.766701]<br /> [ 74.767216] CPU0<br /> [ 74.767437] ----<br /> [ 74.767656] lock(direct_mutex);<br /> [ 74.767952] lock(direct_mutex);<br /> [ 74.768245]<br /> [ 74.768245] *** DEADLOCK ***<br /> [ 74.768245]<br /> [ 74.768750] May be due to missing lock nesting notation<br /> [ 74.768750]<br /> [ 74.769332] 1 lock held by event-sample-fn/1084:<br /> [ 74.769731] #0: ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.770496]<br /> [ 74.770496] stack backtrace:<br /> [ 74.770884] CPU: 4 PID: 1084 Comm: event-sample-fn Not tainted ...<br /> [ 74.771498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...<br /> [ 74.772474] Call Trace:<br /> [ 74.772696] <br /> [ 74.772896] dump_stack_lvl+0x44/0x5b<br /> [ 74.773223] __lock_acquire.cold.74+0xac/0x2b7<br /> [ 74.773616] lock_acquire+0xd2/0x310<br /> [ 74.773936] ? register_ftrace_function+0x1f/0x180<br /> [ 74.774357] ? lock_is_held_type+0xd8/0x130<br /> [ 74.774744] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.775213] __mutex_lock+0x99/0x1010<br /> [ 74.775536] ? register_ftrace_function+0x1f/0x180<br /> [ 74.775954] ? slab_free_freelist_hook.isra.43+0x115/0x160<br /> [ 74.776424] ? ftrace_set_hash+0x195/0x220<br /> [ 74.776779] ? register_ftrace_function+0x1f/0x180<br /> [ 74.777194] ? kfree+0x3e1/0x440<br /> [ 74.777482] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.777941] ? __schedule+0xb40/0xb40<br /> [ 74.778258] ? register_ftrace_function+0x1f/0x180<br /> [ 74.778672] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.779128] register_ftrace_function+0x1f/0x180<br /> [ 74.779527] ? ftrace_set_filter_ip+0x33/0x70<br /> [ 74.779910] ? __schedule+0xb40/0xb40<br /> [ 74.780231] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.780678] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.781147] ftrace_modify_direct_caller+0x5b/0x90<br /> [ 74.781563] ? 0xffffffffa0201000<br /> [ 74.781859] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.782309] modify_ftrace_direct+0x1b2/0x1f0<br /> [ 74.782690] ? __schedule+0xb40/0xb40<br /> [ 74.783014] ? simple_thread+0x2a/0xb0 [ftrace_direct_modify]<br /> [ 74.783508] ? __schedule+0xb40/0xb40<br /> [ 74.783832] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.784294] simple_thread+0x76/0xb0 [ftrace_direct_modify]<br /> [ 74.784766] kthread+0xf5/0x120<br /> [ 74.785052] ? kthread_complete_and_exit+0x20/0x20<br /> [ 74.785464] ret_from_fork+0x22/0x30<br /> [ 74.785781] <br /> <br /> Fix this by using register_ftrace_function_nolock in<br /> ftrace_modify_direct_caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type()<br /> <br /> ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length<br /> of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements<br /> beyond the end of the adp5061_chg_type[] array.