Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Only force 030 bus error if PC not in exception table<br /> <br /> __get_kernel_nofault() does copy data in supervisor mode when<br /> forcing a task backtrace log through /proc/sysrq_trigger.<br /> This is expected cause a bus error exception on e.g. NULL<br /> pointer dereferencing when logging a kernel task has no<br /> workqueue associated. This bus error ought to be ignored.<br /> <br /> Our 030 bus error handler is ill equipped to deal with this:<br /> <br /> Whenever ssw indicates a kernel mode access on a data fault,<br /> we don&amp;#39;t even attempt to handle the fault and instead always<br /> send a SEGV signal (or panic). As a result, the check<br /> for exception handling at the fault PC (buried in<br /> send_sig_fault() which gets called from do_page_fault()<br /> eventually) is never used.<br /> <br /> In contrast, both 040 and 060 access error handlers do not<br /> care whether a fault happened on supervisor mode access,<br /> and will call do_page_fault() on those, ultimately honoring<br /> the exception table.<br /> <br /> Add a check in bus_error030 to call do_page_fault() in case<br /> we do have an entry for the fault PC in our exception table.<br /> <br /> I had attempted a fix for this earlier in 2019 that did rely<br /> on testing pagefault_disabled() (see link below) to achieve<br /> the same thing, but this patch should be more generic.<br /> <br /> Tested on 030 Atari Falcon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: avoid a NULL dereference with unsupported widgets<br /> <br /> If an IPC4 topology contains an unsupported widget, its .module_info<br /> field won&amp;#39;t be set, then sof_ipc4_route_setup() will cause a kernel<br /> Oops trying to dereference it. Add a check for such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix missing mrioc-&gt;evtack_cmds initialization<br /> <br /> Commit c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")<br /> introduced an array mrioc-&gt;evtack_cmds but initialization of the array<br /> elements was missed. They are just zero cleared. The function<br /> mpi3mr_complete_evt_ack() refers host_tag field of the elements. Due to the<br /> zero value of the host_tag field, the function calls clear_bit() for<br /> mrico-&gt;evtack_cmds_bitmap with wrong bit index. This results in memory<br /> access to invalid address and "BUG: KASAN: use-after-free". This BUG was<br /> observed at eHBA-9600 firmware update to version 8.3.1.0. To fix it, add<br /> the missing initialization of mrioc-&gt;evtack_cmds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DOE: Fix destroy_work_on_stack() race<br /> <br /> The following debug object splat was observed in testing:<br /> <br /> ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510<br /> WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0<br /> ...<br /> Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work<br /> RIP: 0010:debug_print_object+0x7d/0xb0<br /> ...<br /> Call Trace:<br /> ? debug_print_object+0x7d/0xb0<br /> ? __pfx_doe_statemachine_work+0x10/0x10<br /> debug_object_free.part.0+0x11b/0x150<br /> doe_statemachine_work+0x45e/0x510<br /> process_one_work+0x1d4/0x3c0<br /> <br /> This occurs because destroy_work_on_stack() was called after signaling<br /> the completion in the calling thread. This creates a race between<br /> destroy_work_on_stack() and the task-&gt;work struct going out of scope in<br /> pci_doe().<br /> <br /> Signal the work complete after destroying the work struct. This is safe<br /> because signal_task_complete() is the final thing the work item does and<br /> the workqueue code is careful not to access the work struct after.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix load-tearing on sk-&gt;sk_stamp in sock_recv_cmsgs().<br /> <br /> KCSAN found a data race in sock_recv_cmsgs() where the read access<br /> to sk-&gt;sk_stamp needs READ_ONCE().<br /> <br /> BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsg<br /> <br /> write (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0:<br /> sock_write_timestamp include/net/sock.h:2670 [inline]<br /> sock_recv_cmsgs include/net/sock.h:2722 [inline]<br /> packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489<br /> sock_recvmsg_nosec net/socket.c:1019 [inline]<br /> sock_recvmsg+0x11a/0x130 net/socket.c:1040<br /> sock_read_iter+0x176/0x220 net/socket.c:1118<br /> call_read_iter include/linux/fs.h:1845 [inline]<br /> new_sync_read fs/read_write.c:389 [inline]<br /> vfs_read+0x5e0/0x630 fs/read_write.c:470<br /> ksys_read+0x163/0x1a0 fs/read_write.c:613<br /> __do_sys_read fs/read_write.c:623 [inline]<br /> __se_sys_read fs/read_write.c:621 [inline]<br /> __x64_sys_read+0x41/0x50 fs/read_write.c:621<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> read to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1:<br /> sock_recv_cmsgs include/net/sock.h:2721 [inline]<br /> packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489<br /> sock_recvmsg_nosec net/socket.c:1019 [inline]<br /> sock_recvmsg+0x11a/0x130 net/socket.c:1040<br /> sock_read_iter+0x176/0x220 net/socket.c:1118<br /> call_read_iter include/linux/fs.h:1845 [inline]<br /> new_sync_read fs/read_write.c:389 [inline]<br /> vfs_read+0x5e0/0x630 fs/read_write.c:470<br /> ksys_read+0x163/0x1a0 fs/read_write.c:613<br /> __do_sys_read fs/read_write.c:623 [inline]<br /> __se_sys_read fs/read_write.c:621 [inline]<br /> __x64_sys_read+0x41/0x50 fs/read_write.c:621<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> value changed: 0xffffffffc4653600 -&gt; 0x0000000000000000<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "IB/isert: Fix incorrect release of isert connection"<br /> <br /> Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") is<br /> causing problems on OPA when DEVICE_REMOVAL is happening.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359<br /> ib_cq_pool_cleanup+0xac/0xb0 [ib_core]<br /> Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc<br /> scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file<br /> rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs<br /> rfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod<br /> opa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm<br /> ib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core<br /> x86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt<br /> ipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma<br /> intel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter<br /> acpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul<br /> crc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci<br /> ghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse<br /> CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1<br /> Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS<br /> SE5C610.86B.01.01.0014.121820151719 12/18/2015<br /> RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core]<br /> Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83<br /> c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0b eb a1<br /> 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f<br /> RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206<br /> RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d<br /> RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640<br /> RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d<br /> R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18<br /> R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38<br /> FS: 00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? __warn+0x80/0x130<br /> ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]<br /> ? report_bug+0x195/0x1a0<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]<br /> disable_device+0x9d/0x160 [ib_core]<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> rvt_unregister_device+0x20/0x90 [rdmavt]<br /> hfi1_unregister_ib_device+0x16/0xf0 [hfi1]<br /> remove_one+0x55/0x1a0 [hfi1]<br /> pci_device_remove+0x36/0xa0<br /> device_release_driver_internal+0x193/0x200<br /> driver_detach+0x44/0x90<br /> bus_remove_driver+0x69/0xf0<br /> pci_unregister_driver+0x2a/0xb0<br /> hfi1_mod_cleanup+0xc/0x3c [hfi1]<br /> __do_sys_delete_module.constprop.0+0x17a/0x2f0<br /> ? exit_to_user_mode_prepare+0xc4/0xd0<br /> ? syscall_trace_enter.constprop.0+0x126/0x1a0<br /> do_syscall_64+0x5c/0x90<br /> ? syscall_exit_to_user_mode+0x12/0x30<br /> ? do_syscall_64+0x69/0x90<br /> ? syscall_exit_work+0x103/0x130<br /> ? syscall_exit_to_user_mode+0x12/0x30<br /> ? do_syscall_64+0x69/0x90<br /> ? exc_page_fault+0x65/0x150<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> RIP: 0033:0x7ff1e643f5ab<br /> Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3<br /> 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 3d 01 f0<br /> ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0<br /> RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab<br /> RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8<br /> RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8<br /> R13: 00000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Fix oops for port-&gt;pm on uart_change_pm()<br /> <br /> Unloading a hardware specific 8250 driver can produce error "Unable to<br /> handle kernel paging request at virtual address" about ten seconds after<br /> unloading the driver. This happens on uart_hangup() calling<br /> uart_change_pm().<br /> <br /> Turns out commit 04e82793f068 ("serial: 8250: Reinit port-&gt;pm on port<br /> specific driver unbind") was only a partial fix. If the hardware specific<br /> driver has initialized port-&gt;pm function, we need to clear port-&gt;pm too.<br /> Just reinitializing port-&gt;ops does not do this. Otherwise serial8250_pm()<br /> will call port-&gt;pm() instead of serial8250_do_pm().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx93: fix memory leak and missing unwind goto in imx93_clocks_probe<br /> <br /> In function probe(), it returns directly without unregistered hws<br /> when error occurs.<br /> <br /> Fix this by adding &amp;#39;goto unregister_hws;&amp;#39; on line 295 and<br /> line 310.<br /> <br /> Use devm_kzalloc() instead of kzalloc() to automatically<br /> free the memory using devm_kfree() when error occurs.<br /> <br /> Replace of_iomap() with devm_of_iomap() to automatically<br /> handle the unused ioremap region and delete &amp;#39;iounmap(anatop_base);&amp;#39;<br /> in unregister_hws.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hte: tegra-194: Fix off by one in tegra_hte_map_to_line_id()<br /> <br /> The "map_sz" is the number of elements in the "m" array so the &gt;<br /> comparison needs to be changed to &gt;= to prevent an out of bounds<br /> read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix invalid buffer access for legacy rq<br /> <br /> The below crash can be encountered when using xdpsock in rx mode for<br /> legacy rq: the buffer gets released in the XDP_REDIRECT path, and then<br /> once again in the driver. This fix sets the flag to avoid releasing on<br /> the driver side.<br /> <br /> XSK handling of buffers for legacy rq was relying on the caller to set<br /> the skip release flag. But the referenced fix started using fragment<br /> counts for pages instead of the skip flag.<br /> <br /> Crash log:<br /> general protection fault, probably for non-canonical address 0xffff8881217e3a: 0000 [#1] SMP<br /> CPU: 0 PID: 14 Comm: ksoftirqd/0 Not tainted 6.5.0-rc1+ #31<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:bpf_prog_03b13f331978c78c+0xf/0x28<br /> Code: ...<br /> RSP: 0018:ffff88810082fc98 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888138404901 RCX: c0ffffc900027cbc<br /> RDX: ffffffffa000b514 RSI: 00ffff8881217e32 RDI: ffff888138404901<br /> RBP: ffff88810082fc98 R08: 0000000000091100 R09: 0000000000000006<br /> R10: 0000000000000800 R11: 0000000000000800 R12: ffffc9000027a000<br /> R13: ffff8881217e2dc0 R14: ffff8881217e2910 R15: ffff8881217e2f00<br /> FS: 0000000000000000(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564cb2e2cde0 CR3: 000000010e603004 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x32/0x80<br /> ? exc_general_protection+0x192/0x390<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? 0xffffffffa000b514<br /> ? bpf_prog_03b13f331978c78c+0xf/0x28<br /> mlx5e_xdp_handle+0x48/0x670 [mlx5_core]<br /> ? dev_gro_receive+0x3b5/0x6e0<br /> mlx5e_xsk_skb_from_cqe_linear+0x6e/0x90 [mlx5_core]<br /> mlx5e_handle_rx_cqe+0x55/0x100 [mlx5_core]<br /> mlx5e_poll_rx_cq+0x87/0x6e0 [mlx5_core]<br /> mlx5e_napi_poll+0x45e/0x6b0 [mlx5_core]<br /> __napi_poll+0x25/0x1a0<br /> net_rx_action+0x28a/0x300<br /> __do_softirq+0xcd/0x279<br /> ? sort_range+0x20/0x20<br /> run_ksoftirqd+0x1a/0x20<br /> smpboot_thread_fn+0xa2/0x130<br /> kthread+0xc9/0xf0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br /> <br /> Modules linked in: mlx5_ib mlx5_core rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay zram zsmalloc fuse [last unloaded: mlx5_core]<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix lockdep splat and potential deadlock after failure running delayed items<br /> <br /> When running delayed items we are holding a delayed node&amp;#39;s mutex and then<br /> we will attempt to modify a subvolume btree to insert/update/delete the<br /> delayed items. However if have an error during the insertions for example,<br /> btrfs_insert_delayed_items() may return with a path that has locked extent<br /> buffers (a leaf at the very least), and then we attempt to release the<br /> delayed node at __btrfs_run_delayed_items(), which requires taking the<br /> delayed node&amp;#39;s mutex, causing an ABBA type of deadlock. This was reported<br /> by syzbot and the lockdep splat is the following:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor.2/13257 is trying to acquire lock:<br /> ffff88801835c0c0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256<br /> <br /> but task is already holding lock:<br /> ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> __lock_release kernel/locking/lockdep.c:5475 [inline]<br /> lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781<br /> up_write+0x79/0x580 kernel/locking/rwsem.c:1625<br /> btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline]<br /> btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239<br /> search_leaf fs/btrfs/ctree.c:1986 [inline]<br /> btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230<br /> btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376<br /> btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline]<br /> btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline]<br /> __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111<br /> __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153<br /> flush_space+0x269/0xe70 fs/btrfs/space-info.c:723<br /> btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078<br /> process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600<br /> worker_thread+0xa63/0x1210 kernel/workqueue.c:2751<br /> kthread+0x2b8/0x350 kernel/kthread.c:389<br /> ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> check_prev_add kernel/locking/lockdep.c:3142 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3261 [inline]<br /> validate_chain kernel/locking/lockdep.c:3876 [inline]<br /> __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761<br /> __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603<br /> __mutex_lock kernel/locking/mutex.c:747 [inline]<br /> mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799<br /> __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256<br /> btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline]<br /> __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156<br /> btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276<br /> btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988<br /> vfs_fsync_range fs/sync.c:188 [inline]<br /> vfs_fsync fs/sync.c:202 [inline]<br /> do_fsync fs/sync.c:212 [inline]<br /> __do_sys_fsync fs/sync.c:220 [inline]<br /> __se_sys_fsync fs/sync.c:218 [inline]<br /> __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> other info that<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipa: only reset hashed tables when supported<br /> <br /> Last year, the code that manages GSI channel transactions switched<br /> from using spinlock-protected linked lists to using indexes into the<br /> ring buffer used for a channel. Recently, Google reported seeing<br /> transaction reference count underflows occasionally during shutdown.<br /> <br /> Doug Anderson found a way to reproduce the issue reliably, and<br /> bisected the issue to the commit that eliminated the linked lists<br /> and the lock. The root cause was ultimately determined to be<br /> related to unused transactions being committed as part of the modem<br /> shutdown cleanup activity. Unused transactions are not normally<br /> expected (except in error cases).<br /> <br /> The modem uses some ranges of IPA-resident memory, and whenever it<br /> shuts down we zero those ranges. In ipa_filter_reset_table() a<br /> transaction is allocated to zero modem filter table entries. If<br /> hashing is not supported, hashed table memory should not be zeroed.<br /> But currently nothing prevents that, and the result is an unused<br /> transaction. Something similar occurs when we zero routing table<br /> entries for the modem.<br /> <br /> By preventing any attempt to clear hashed tables when hashing is not<br /> supported, the reference count underflow is avoided in this case.<br /> <br /> Note that there likely remains an issue with properly freeing unused<br /> transactions (if they occur due to errors). This patch addresses<br /> only the underflows that Google originally reported.