Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: Fix potential null-ptr-deref in lan966x_stats_init()<br /> <br /> lan966x_stats_init() calls create_singlethread_workqueue() and not<br /> checked the ret value, which may return NULL. And a null-ptr-deref may<br /> happen:<br /> <br /> lan966x_stats_init()<br /> create_singlethread_workqueue() # failed, lan966x-&gt;stats_queue is NULL<br /> queue_delayed_work()<br /> queue_delayed_work_on()<br /> __queue_delayed_work() # warning here, but continue<br /> __queue_work() # access wq-&gt;flags, null-ptr-deref<br /> <br /> Check the ret value and return -ENOMEM if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()<br /> <br /> sparx_stats_init() calls create_singlethread_workqueue() and not<br /> checked the ret value, which may return NULL. And a null-ptr-deref may<br /> happen:<br /> <br /> sparx_stats_init()<br /> create_singlethread_workqueue() # failed, sparx5-&gt;stats_queue is NULL<br /> queue_delayed_work()<br /> queue_delayed_work_on()<br /> __queue_delayed_work() # warning here, but continue<br /> __queue_work() # access wq-&gt;flags, null-ptr-deref<br /> <br /> Check the ret value and return -ENOMEM if it is NULL. So as<br /> sparx5_start().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race where eprobes can be called before the event<br /> <br /> The flag that tells the event to call its triggers after reading the event<br /> is set for eprobes after the eprobe is enabled. This leads to a race where<br /> the eprobe may be triggered at the beginning of the event where the record<br /> information is NULL. The eprobe then dereferences the NULL record causing<br /> a NULL kernel pointer bug.<br /> <br /> Test for a NULL record to keep this from happening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix wild-memory-access in register_synth_event()<br /> <br /> In register_synth_event(), if set_synth_event_print_fmt() failed, then<br /> both trace_remove_event_call() and unregister_trace_event() will be<br /> called, which means the trace_event_call will call<br /> __unregister_trace_event() twice. As the result, the second unregister<br /> will causes the wild-memory-access.<br /> <br /> register_synth_event<br /> set_synth_event_print_fmt failed<br /> trace_remove_event_call<br /> event_remove<br /> if call-&gt;event.funcs then<br /> __unregister_trace_event (first call)<br /> unregister_trace_event<br /> __unregister_trace_event (second call)<br /> <br /> Fix the bug by avoiding to call the second __unregister_trace_event() by<br /> checking if the first one is called.<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI<br /> KASAN: maybe wild-memory-access in range<br /> [0xdead000000000120-0xdead000000000127]<br /> CPU: 0 PID: 3807 Comm: modprobe Not tainted<br /> 6.1.0-rc1-00186-g76f33a7eedb4 #299<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:unregister_trace_event+0x6e/0x280<br /> Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48<br /> b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 3c 02<br /> 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b<br /> RSP: 0018:ffff88810413f370 EFLAGS: 00010a06<br /> RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000<br /> RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20<br /> RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481<br /> R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122<br /> R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028<br /> FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __create_synth_event+0x1e37/0x1eb0<br /> create_or_delete_synth_event+0x110/0x250<br /> synth_event_run_command+0x2f/0x110<br /> test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test]<br /> synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test]<br /> do_one_initcall+0xdb/0x480<br /> do_init_module+0x1cf/0x680<br /> load_module+0x6a50/0x70a0<br /> __do_sys_finit_module+0x12f/0x1c0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()<br /> <br /> test_gen_synth_cmd() only free buf in fail path, hence buf will leak<br /> when there is no failure. Add kfree(buf) to prevent the memleak. The<br /> same reason and solution in test_empty_synth_event().<br /> <br /> unreferenced object 0xffff8881127de000 (size 2048):<br /> comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s)<br /> hex dump (first 32 bytes):<br /> 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test<br /> 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x100<br /> [] 0xffffffffa00083cd<br /> [] 0xffffffffa00086ba<br /> [] do_one_initcall+0xdb/0x480<br /> [] do_init_module+0x1cf/0x680<br /> [] load_module+0x6a50/0x70a0<br /> [] __do_sys_finit_module+0x12f/0x1c0<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> unreferenced object 0xffff8881127df000 (size 2048):<br /> comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s)<br /> hex dump (first 32 bytes):<br /> 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes<br /> 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x100<br /> [] 0xffffffffa0008071<br /> [] 0xffffffffa00086ce<br /> [] do_one_initcall+0xdb/0x480<br /> [] do_init_module+0x1cf/0x680<br /> [] load_module+0x6a50/0x70a0<br /> [] __do_sys_finit_module+0x12f/0x1c0<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix memory leak in tracing_read_pipe()<br /> <br /> kmemleak reports this issue:<br /> <br /> unreferenced object 0xffff888105a18900 (size 128):<br /> comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s)<br /> hex dump (first 32 bytes):<br /> 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&amp;...B.X.<br /> 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4a/0x140<br /> [] krealloc+0x8d/0xf0<br /> [] trace_iter_expand_format+0x99/0x150<br /> [] trace_check_vprintf+0x1e0/0x11d0<br /> [] trace_event_printf+0xb6/0xf0<br /> [] trace_raw_output_bpf_trace_printk+0x89/0xc0<br /> [] print_trace_line+0x73c/0x1480<br /> [] tracing_read_pipe+0x45c/0x9f0<br /> [] vfs_read+0x17b/0x7c0<br /> [] ksys_read+0xed/0x1c0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> iter-&gt;fmt alloced in<br /> tracing_read_pipe() -&gt; .. -&gt;trace_iter_expand_format(), but not<br /> freed, to fix, add free in tracing_release_pipe()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - invert valid length check when fetching device IDs<br /> <br /> syzbot is reporting uninitialized value at iforce_init_device() [1], for<br /> commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer<br /> when fetching device IDs") is checking that valid length is shorter than<br /> bytes to read. Since iforce_get_id_packet() stores valid length when<br /> returning 0, the caller needs to check that valid length is longer than or<br /> equals to bytes to read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix multishot accept request leaks<br /> <br /> Having REQ_F_POLLED set doesn&amp;#39;t guarantee that the request is<br /> executed as a multishot from the polling path. Fortunately for us, if<br /> the code thinks it&amp;#39;s multishot issue when it&amp;#39;s not, it can only ask to<br /> skip completion so leaking the request. Use issue_flags to mark<br /> multipoll issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: mp2629: fix potential array out of bound access<br /> <br /> Add sentinel at end of maps to avoid potential array out of<br /> bound access in iio core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()<br /> <br /> dev_set_name() allocates memory for name, it need be freed<br /> when device_add() fails, call put_device() to give up the<br /> reference that hold in device_initialize(), so that it can<br /> be freed in kobject_cleanup() when the refcount hit to 0.<br /> <br /> Fault injection test can trigger this:<br /> <br /> unreferenced object 0xffff8e8340a7b4c0 (size 32):<br /> comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s)<br /> hex dump (first 32 bytes):<br /> 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge<br /> 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e9/0x360<br /> [] __kmalloc_node_track_caller+0x44/0x1a0<br /> [] kstrdup+0x2d/0x60<br /> [] kobject_set_name_vargs+0x1e/0x90<br /> [] dev_set_name+0x4e/0x70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()<br /> <br /> If iio_trigger_register() returns error, it should call iio_trigger_free()<br /> to give up the reference that hold in iio_trigger_alloc(), so that it can<br /> call iio_trig_release() to free memory when the refcount hit to 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rethook: fix a potential memleak in rethook_alloc()<br /> <br /> In rethook_alloc(), the variable rh is not freed or passed out<br /> if handler is NULL, which could lead to a memleak, fix it.<br /> <br /> [Masami: Add "rethook:" tag to the title.]<br /> <br /> Acke-by: Masami Hiramatsu (Google)