Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a memory leak in nvmet_auth_set_key<br /> <br /> When changing dhchap secrets we need to release the old<br /> secrets as well.<br /> <br /> kmemleak complaint:<br /> --<br /> unreferenced object 0xffff8c7f44ed8180 (size 64):<br /> comm "check", pid 7304, jiffies 4295686133 (age 72034.246s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq<br /> 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8<br /> backtrace:<br /> [] kstrdup+0x2e/0x60<br /> [] 0xffffffffc0e07ee6<br /> [] 0xffffffffc0dff783<br /> [] configfs_write_iter+0xb1/0x120<br /> [] vfs_write+0x2be/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x38/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: don&amp;#39;t leak tagger-owned storage on switch driver unbind<br /> <br /> In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned<br /> storage for private and shared data"), we had a call to<br /> tag_ops-&gt;disconnect(dst) issued from dsa_tree_free(), which is called at<br /> tree teardown time.<br /> <br /> There were problems with connecting to a switch tree as a whole, so this<br /> got reworked to connecting to individual switches within the tree. In<br /> this process, tag_ops-&gt;disconnect(ds) was made to be called only from<br /> switch.c (cross-chip notifiers emitted as a result of dynamic tag proto<br /> changes), but the normal driver teardown code path wasn&amp;#39;t replaced with<br /> anything.<br /> <br /> Solve this problem by adding a function that does the opposite of<br /> dsa_switch_setup_tag_protocol(), which is called from the equivalent<br /> spot in dsa_switch_teardown(). The positioning here also ensures that we<br /> won&amp;#39;t have any use-after-free in tagging protocol (*rcv) ops, since the<br /> teardown sequence is as follows:<br /> <br /> dsa_tree_teardown<br /> -&gt; dsa_tree_teardown_master<br /> -&gt; dsa_master_teardown<br /> -&gt; unsets master-&gt;dsa_ptr, making no further packets match the<br /> ETH_P_XDSA packet type handler<br /> -&gt; dsa_tree_teardown_ports<br /> -&gt; dsa_port_teardown<br /> -&gt; dsa_slave_destroy<br /> -&gt; unregisters DSA net devices, there is even a synchronize_net()<br /> in unregister_netdevice_many()<br /> -&gt; dsa_tree_teardown_switches<br /> -&gt; dsa_switch_teardown<br /> -&gt; dsa_switch_teardown_tag_protocol<br /> -&gt; finally frees the tagger-owned storage

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix missing xas_retry() calls in xarray iteration<br /> <br /> netfslib has a number of places in which it performs iteration of an xarray<br /> whilst being under the RCU read lock. It *should* call xas_retry() as the<br /> first thing inside of the loop and do "continue" if it returns true in case<br /> the xarray walker passed out a special value indicating that the walk needs<br /> to be redone from the root[*].<br /> <br /> Fix this by adding the missing retry checks.<br /> <br /> [*] I wonder if this should be done inside xas_find(), xas_next_node() and<br /> suchlike, but I&amp;#39;m told that&amp;#39;s not an simple change to effect.<br /> <br /> This can cause an oops like that below. Note the faulting address - this<br /> is an internal value (|0x2) returned from xarray.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000402<br /> ...<br /> RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]<br /> ...<br /> Call Trace:<br /> netfs_rreq_assess+0xa6/0x240 [netfs]<br /> netfs_readpage+0x173/0x3b0 [netfs]<br /> ? init_wait_var_entry+0x50/0x50<br /> filemap_read_page+0x33/0xf0<br /> filemap_get_pages+0x2f2/0x3f0<br /> filemap_read+0xaa/0x320<br /> ? do_filp_open+0xb2/0x150<br /> ? rmqueue+0x3be/0xe10<br /> ceph_read_iter+0x1fe/0x680 [ceph]<br /> ? new_sync_read+0x115/0x1a0<br /> new_sync_read+0x115/0x1a0<br /> vfs_read+0xf3/0x180<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Changes:<br /> ========<br /> ver #2)<br /> - Changed an unsigned int to a size_t to reduce the likelihood of an<br /> overflow as per Willy&amp;#39;s suggestion.<br /> - Added an additional patch to fix the maths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix skb leak in x25_lapb_receive_frame()<br /> <br /> x25_lapb_receive_frame() using skb_copy() to get a private copy of<br /> skb, the new skb should be freed in the undersized/fragmented skb<br /> error handling path. Otherwise there is a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix null pointer dereference in ftrace_add_mod()<br /> <br /> The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next}<br /> of @ftrace_mode-&gt;list are NULL, it&amp;#39;s not a valid state to call list_del().<br /> If kstrdup() for @ftrace_mod-&gt;{func|module} fails, it goes to @out_free<br /> tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del()<br /> will write prev-&gt;next and next-&gt;prev, where null pointer dereference<br /> happens.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> Call Trace:<br /> <br /> ftrace_mod_callback+0x20d/0x220<br /> ? do_filp_open+0xd9/0x140<br /> ftrace_process_regex.isra.51+0xbf/0x130<br /> ftrace_regex_write.isra.52.part.53+0x6e/0x90<br /> vfs_write+0xee/0x3a0<br /> ? __audit_filter_op+0xb1/0x100<br /> ? auditd_test_task+0x38/0x50<br /> ksys_write+0xa5/0xe0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> So call INIT_LIST_HEAD() to initialize the list member to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: Fix memory leak of nsim_dev-&gt;fa_cookie<br /> <br /> kmemleak reports this issue:<br /> <br /> unreferenced object 0xffff8881bac872d0 (size 8):<br /> comm "sh", pid 58603, jiffies 4481524462 (age 68.065s)<br /> hex dump (first 8 bytes):<br /> 04 00 00 00 de ad be ef ........<br /> backtrace:<br /> [] __kmalloc+0x49/0x150<br /> [] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim]<br /> [] full_proxy_write+0xf3/0x180<br /> [] vfs_write+0x1c5/0xaf0<br /> [] ksys_write+0xed/0x1c0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The issue occurs in the following scenarios:<br /> <br /> nsim_dev_trap_fa_cookie_write()<br /> kmalloc() fa_cookie<br /> nsim_dev-&gt;fa_cookie = fa_cookie<br /> ..<br /> nsim_drv_remove()<br /> <br /> The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To<br /> fix, add kfree(nsim_dev-&gt;fa_cookie) to nsim_drv_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390: avoid using global register for current_stack_pointer<br /> <br /> Commit 30de14b1884b ("s390: current_stack_pointer shouldn&amp;#39;t be a<br /> function") made current_stack_pointer a global register variable like<br /> on many other architectures. Unfortunately on s390 it uncovers old<br /> gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87<br /> ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")]<br /> and backported to gcc-8.4 and later. Due to this bug gcc versions prior<br /> to 8.4 generate broken code which leads to stack corruptions.<br /> <br /> Current minimal gcc version required to build the kernel is declared<br /> as 5.1. It is not possible to fix all old gcc versions, so work<br /> around this problem by avoiding using global register variable for<br /> current_stack_pointer.

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