Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: use memset avoid memory leaks<br /> <br /> Use memset to initialize structs to prevent memory leaks<br /> in l2cap_ecred_connect

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sfc: add missing xdp queue reinitialization<br /> <br /> After rx/tx ring buffer size is changed, kernel panic occurs when<br /> it acts XDP_TX or XDP_REDIRECT.<br /> <br /> When tx/rx ring buffer size is changed(ethtool -G), sfc driver<br /> reallocates and reinitializes rx and tx queues and their buffer<br /> (tx_queue-&gt;buffer).<br /> But it misses reinitializing xdp queues(efx-&gt;xdp_tx_queues).<br /> So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized<br /> tx_queue-&gt;buffer.<br /> <br /> A new function efx_set_xdp_channels() is separated from efx_set_channels()<br /> to handle only xdp queues.<br /> <br /> Splat looks like:<br /> BUG: kernel NULL pointer dereference, address: 000000000000002a<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#4] PREEMPT SMP NOPTI<br /> RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]<br /> CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf<br /> Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80<br /> RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297<br /> RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]<br /> RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870<br /> RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0<br /> RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040<br /> R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0<br /> FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80<br /> CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0<br /> RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297<br /> PKRU: 55555554<br /> RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870<br /> RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700<br /> RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040<br /> R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700<br /> FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> ? enqueue_task_fair+0x95/0x550<br /> efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Avoid writeback threads getting stuck in mempool_alloc()<br /> <br /> In a low memory situation, allow the NFS writeback code to fail without<br /> getting stuck in infinite loops in mempool_alloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Fix potential crash on module unload<br /> <br /> The vmbus driver relies on the panic notifier infrastructure to perform<br /> some operations when a panic event is detected. Since vmbus can be built<br /> as module, it is required that the driver handles both registering and<br /> unregistering such panic notifier callback.<br /> <br /> After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")<br /> though, the panic notifier registration is done unconditionally in the module<br /> initialization routine whereas the unregistering procedure is conditionally<br /> guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability<br /> is set.<br /> <br /> This patch fixes that by unconditionally unregistering the panic notifier<br /> in the module&amp;#39;s exit routine as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Fix initialization of device object in vmbus_device_register()<br /> <br /> Initialize the device&amp;#39;s dma_{mask,parms} pointers and the device&amp;#39;s<br /> dma_mask value before invoking device_register(). Address the<br /> following trace with 5.17-rc7:<br /> <br /> [ 49.646839] WARNING: CPU: 0 PID: 189 at include/linux/dma-mapping.h:543<br /> netvsc_probe+0x37a/0x3a0 [hv_netvsc]<br /> [ 49.646928] Call Trace:<br /> [ 49.646930] <br /> [ 49.646935] vmbus_probe+0x40/0x60 [hv_vmbus]<br /> [ 49.646942] really_probe+0x1ce/0x3b0<br /> [ 49.646948] __driver_probe_device+0x109/0x180<br /> [ 49.646952] driver_probe_device+0x23/0xa0<br /> [ 49.646955] __device_attach_driver+0x76/0xe0<br /> [ 49.646958] ? driver_allows_async_probing+0x50/0x50<br /> [ 49.646961] bus_for_each_drv+0x84/0xd0<br /> [ 49.646964] __device_attach+0xed/0x170<br /> [ 49.646967] device_initial_probe+0x13/0x20<br /> [ 49.646970] bus_probe_device+0x8f/0xa0<br /> [ 49.646973] device_add+0x41a/0x8e0<br /> [ 49.646975] ? hrtimer_init+0x28/0x80<br /> [ 49.646981] device_register+0x1b/0x20<br /> [ 49.646983] vmbus_device_register+0x5e/0xf0 [hv_vmbus]<br /> [ 49.646991] vmbus_add_channel_work+0x12d/0x190 [hv_vmbus]<br /> [ 49.646999] process_one_work+0x21d/0x3f0<br /> [ 49.647002] worker_thread+0x4a/0x3b0<br /> [ 49.647005] ? process_one_work+0x3f0/0x3f0<br /> [ 49.647007] kthread+0xff/0x130<br /> [ 49.647011] ? kthread_complete_and_exit+0x20/0x20<br /> [ 49.647015] ret_from_fork+0x22/0x30<br /> [ 49.647020] <br /> [ 49.647021] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_console: eliminate anonymous module_init &amp; module_exit<br /> <br /> Eliminate anonymous module_init() and module_exit(), which can lead to<br /> confusion or ambiguity when reading System.map, crashes/oops/bugs,<br /> or an initcall_debug log.<br /> <br /> Give each of these init and exit functions unique driver-specific<br /> names to eliminate the anonymous names.<br /> <br /> Example 1: (System.map)<br /> ffffffff832fc78c t init<br /> ffffffff832fc79e t init<br /> ffffffff832fc8f8 t init<br /> <br /> Example 2: (initcall_debug log)<br /> calling init+0x0/0x12 @ 1<br /> initcall init+0x0/0x12 returned 0 after 15 usecs<br /> calling init+0x0/0x60 @ 1<br /> initcall init+0x0/0x60 returned 0 after 2 usecs<br /> calling init+0x0/0x9a @ 1<br /> initcall init+0x0/0x9a returned 0 after 74 usecs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> habanalabs: fix possible memory leak in MMU DR fini<br /> <br /> This patch fixes what seems to be copy paste error.<br /> <br /> We will have a memory leak if the host-resident shadow is NULL (which<br /> will likely happen as the DR and HR are not dependent).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify()<br /> <br /> [You don&amp;#39;t often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]<br /> <br /> The reference counting issue happens in two error paths in the<br /> function _nfs42_proc_copy_notify(). In both error paths, the function<br /> simply returns the error code and forgets to balance the refcount of<br /> object `ctx`, bumped by get_nfs_open_context() earlier, which may<br /> cause refcount leaks.<br /> <br /> Fix it by balancing refcount of the `ctx` object before the function<br /> returns in both error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vchiq_core: handle NULL result of find_service_by_handle<br /> <br /> In case of an invalid handle the function find_servive_by_handle<br /> returns NULL. So take care of this and avoid a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: wfx: fix an error handling in wfx_init_common()<br /> <br /> One error handler of wfx_init_common() return without calling<br /> ieee80211_free_hw(hw), which may result in memory leak. And I add<br /> one err label to unify the error handler, which is useful for the<br /> subsequent changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: fix a race in rxrpc_exit_net()<br /> <br /> Current code can lead to the following race:<br /> <br /> CPU0 CPU1<br /> <br /> rxrpc_exit_net()<br /> rxrpc_peer_keepalive_worker()<br /> if (rxnet-&gt;live)<br /> <br /> rxnet-&gt;live = false;<br /> del_timer_sync(&amp;rxnet-&gt;peer_keepalive_timer);<br /> <br /> timer_reduce(&amp;rxnet-&gt;peer_keepalive_timer, jiffies + delay);<br /> <br /> cancel_work_sync(&amp;rxnet-&gt;peer_keepalive_work);<br /> <br /> rxrpc_exit_net() exits while peer_keepalive_timer is still armed,<br /> leading to use-after-free.<br /> <br /> syzbot report was:<br /> <br /> ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0<br /> WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Modules linked in:<br /> CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3<br /> RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000<br /> RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0<br /> R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]<br /> debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023<br /> kfree+0xd6/0x310 mm/slab.c:3809<br /> ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176<br /> ops_free_list net/core/net_namespace.c:174 [inline]<br /> cleanup_net+0x591/0xb00 net/core/net_namespace.c:598<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298<br />