Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path<br /> <br /> The xiic_xfer() function gets a runtime PM reference when the function is<br /> entered. This reference is released when the function is exited. There is<br /> currently one error path where the function exits directly, which leads to<br /> a leak of the runtime PM reference.<br /> <br /> Make sure that this error path also releases the runtime PM reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: stricter state check in mptcp_worker<br /> <br /> As reported by Christoph, the mptcp protocol can run the<br /> worker when the relevant msk socket is in an unexpected state:<br /> <br /> connect()<br /> // incoming reset + fastclose<br /> // the mptcp worker is scheduled<br /> mptcp_disconnect()<br /> // msk is now CLOSED<br /> listen()<br /> mptcp_worker()<br /> <br /> Leading to the following splat:<br /> <br /> divide error: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018<br /> RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293<br /> RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004<br /> RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000<br /> R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_select_window net/ipv4/tcp_output.c:262 [inline]<br /> __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]<br /> tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459<br /> mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]<br /> mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705<br /> process_one_work+0x3bd/0x950 kernel/workqueue.c:2390<br /> worker_thread+0x5b/0x610 kernel/workqueue.c:2537<br /> kthread+0x138/0x170 kernel/kthread.c:376<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> <br /> This change addresses the issue explicitly checking for bad states<br /> before running the mptcp worker.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: fix warning in dqgrab()<br /> <br /> There&amp;#39;s issue as follows when do fault injection:<br /> WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0<br /> Modules linked in:<br /> CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541<br /> RIP: 0010:dquot_disable+0x13b7/0x18c0<br /> RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980<br /> RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002<br /> RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130<br /> R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118<br /> FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dquot_load_quota_sb+0xd53/0x1060<br /> dquot_resume+0x172/0x230<br /> ext4_reconfigure+0x1dc6/0x27b0<br /> reconfigure_super+0x515/0xa90<br /> __x64_sys_fsconfig+0xb19/0xd20<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Above issue may happens as follows:<br /> ProcessA ProcessB ProcessC<br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_suspend -&gt; suspend all type quota<br /> <br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_resume<br /> ret = dquot_load_quota_sb<br /> add_dquot_ref<br /> do_open -&gt; open file O_RDWR<br /> vfs_open<br /> do_dentry_open<br /> get_write_access<br /> atomic_inc_unless_negative(&amp;inode-&gt;i_writecount)<br /> ext4_file_open<br /> dquot_file_open<br /> dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> atomic_inc(&amp;dquot-&gt;dq_count);<br /> <br /> __dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> if (!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> ext4_acquire_dquot<br /> -&gt; Return error DQ_ACTIVE_B flag isn&amp;#39;t set<br /> dquot_disable<br /> invalidate_dquots<br /> if (atomic_read(&amp;dquot-&gt;dq_count))<br /> dqgrab<br /> WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> -&gt; Trigger warning<br /> <br /> In the above scenario, &amp;#39;dquot-&gt;dq_flags&amp;#39; has no DQ_ACTIVE_B is normal when<br /> dqgrab().<br /> To solve above issue just replace the dqgrab() use in invalidate_dquots() with<br /> atomic_inc(&amp;dquot-&gt;dq_count).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()<br /> <br /> when kmalloc() fail to allocate memory in kasprintf(), name<br /> or full_name will be NULL, strcmp() will cause<br /> null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Array index may go out of bound<br /> <br /> Klocwork reports array &amp;#39;vha-&gt;host_str&amp;#39; of size 16 may use index value(s)<br /> 16..19. Use snprintf() instead of sprintf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle case when repair happens with dev-replace<br /> <br /> [BUG]<br /> There is a bug report that a BUG_ON() in btrfs_repair_io_failure()<br /> (originally repair_io_failure() in v6.0 kernel) got triggered when<br /> replacing a unreliable disk:<br /> <br /> BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3<br /> kernel BUG at fs/btrfs/extent_io.c:2380!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2<br /> Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs]<br /> Call Trace:<br /> <br /> clean_io_failure+0x14d/0x180 [btrfs]<br /> end_bio_extent_readpage+0x412/0x6e0 [btrfs]<br /> ? __switch_to+0x106/0x420<br /> process_one_work+0x1c7/0x380<br /> worker_thread+0x4d/0x380<br /> ? rescuer_thread+0x3a0/0x3a0<br /> kthread+0xe9/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> [CAUSE]<br /> <br /> Before the BUG_ON(), we got some read errors from the replace target<br /> first, note the mirror number (3, which is beyond RAID1 duplication,<br /> thus it&amp;#39;s read from the replace target device).<br /> <br /> Then at the BUG_ON() location, we are trying to writeback the repaired<br /> sectors back the failed device.<br /> <br /> The check looks like this:<br /> <br /> ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical,<br /> &amp;map_length, &amp;bioc, mirror_num);<br /> if (ret)<br /> goto out_counter_dec;<br /> BUG_ON(mirror_num != bioc-&gt;mirror_num);<br /> <br /> But inside btrfs_map_block(), we can modify bioc-&gt;mirror_num especially<br /> for dev-replace:<br /> <br /> if (dev_replace_is_ongoing &amp;&amp; mirror_num == map-&gt;num_stripes + 1 &amp;&amp;<br /> !need_full_stripe(op) &amp;&amp; dev_replace-&gt;tgtdev != NULL) {<br /> ret = get_extra_mirror_from_replace(fs_info, logical, *length,<br /> dev_replace-&gt;srcdev-&gt;devid,<br /> &amp;mirror_num,<br /> &amp;physical_to_patch_in_first_stripe);<br /> patch_the_first_stripe_for_dev_replace = 1;<br /> }<br /> <br /> Thus if we&amp;#39;re repairing the replace target device, we&amp;#39;re going to<br /> trigger that BUG_ON().<br /> <br /> But in reality, the read failure from the replace target device may be<br /> that, our replace hasn&amp;#39;t reached the range we&amp;#39;re reading, thus we&amp;#39;re<br /> reading garbage, but with replace running, the range would be properly<br /> filled later.<br /> <br /> Thus in that case, we don&amp;#39;t need to do anything but let the replace<br /> routine to handle it.<br /> <br /> [FIX]<br /> Instead of a BUG_ON(), just skip the repair if we&amp;#39;re repairing the<br /> device replace target device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm integrity: Fix UAF in dm_integrity_dtr()<br /> <br /> Dm_integrity also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in dm_integrity_dtr().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: fix iso_conn related locking and validity issues<br /> <br /> sk-&gt;sk_state indicates whether iso_pi(sk)-&gt;conn is valid. Operations<br /> that check/update sk_state and access conn should hold lock_sock,<br /> otherwise they can race.<br /> <br /> The order of taking locks is hci_dev_lock &gt; lock_sock &gt; iso_conn_lock,<br /> which is how it is in connect/disconnect_cfm -&gt; iso_conn_del -&gt;<br /> iso_chan_del.<br /> <br /> Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sock<br /> around updating sk_state and conn.<br /> <br /> iso_conn_del must not occur during iso_connect_cis/bis, as it frees the<br /> iso_conn. Hold hdev-&gt;lock longer to prevent that.<br /> <br /> This should not reintroduce the issue fixed in commit 241f51931c35<br /> ("Bluetooth: ISO: Avoid circular locking dependency"), since the we<br /> acquire locks in order. We retain the fix in iso_sock_connect to release<br /> lock_sock before iso_connect_* acquires hdev-&gt;lock.<br /> <br /> Similarly for commit 6a5ad251b7cd ("Bluetooth: ISO: Fix possible<br /> circular locking dependency"). We retain the fix in iso_conn_ready to<br /> not acquire iso_conn_lock before lock_sock.<br /> <br /> iso_conn_add shall return iso_conn with valid hcon. Make it so also when<br /> reusing an old CIS connection waiting for disconnect timeout (see<br /> __iso_sock_close where conn-&gt;hcon is set to NULL).<br /> <br /> Trace with iso_conn_del after iso_chan_add in iso_connect_cis:<br /> ===============================================================<br /> iso_sock_create:771: sock 00000000be9b69b7<br /> iso_sock_init:693: sk 000000004dff667e<br /> iso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_connect:875: sk 000000004dff667e<br /> iso_connect_cis:353: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> hci_get_route:1199: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> hci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:da<br /> iso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e<br /> __iso_chan_add:214: conn 00000000daf8625e<br /> iso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12<br /> iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16<br /> iso_sock_clear_timer:117: sock 000000004dff667e state 3<br /> <br /> iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16<br /> hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535<br /> hci_conn_unlink:1102: hci0: hcon 000000007b65d182<br /> hci_chan_list_flush:2780: hcon 000000007b65d182<br /> iso_sock_getsockopt:1376: sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getsockopt:1376: sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_shutdown:1434: sock 00000000be9b69b7, sk 000000004dff667e, how 1<br /> __iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> RIP: 0010:__iso_sock_close (net/bluetooth/iso.c:664) bluetooth<br /> ===============================================================<br /> <br /> Trace with iso_conn_del before iso_chan_add in iso_connect_cis:<br /> ===============================================================<br /> iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> ...<br /> iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504<br /> hci_dev_put:1487: hci0 orig refcnt 21<br /> hci_event_packet:7607: hci0: e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zsmalloc: move LRU update from zs_map_object() to zs_malloc()<br /> <br /> Under memory pressure, we sometimes observe the following crash:<br /> <br /> [ 5694.832838] ------------[ cut here ]------------<br /> [ 5694.842093] list_del corruption, ffff888014b6a448-&gt;next is LIST_POISON1 (dead000000000100)<br /> [ 5694.858677] WARNING: CPU: 33 PID: 418824 at lib/list_debug.c:47 __list_del_entry_valid+0x42/0x80<br /> [ 5694.961820] CPU: 33 PID: 418824 Comm: fuse_counters.s Kdump: loaded Tainted: G S 5.19.0-0_fbk3_rc3_hoangnhatpzsdynshrv41_10870_g85a9558a25de #1<br /> [ 5694.990194] Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM16 05/24/2021<br /> [ 5695.007072] RIP: 0010:__list_del_entry_valid+0x42/0x80<br /> [ 5695.017351] Code: 08 48 83 c2 22 48 39 d0 74 24 48 8b 10 48 39 f2 75 2c 48 8b 51 08 b0 01 48 39 f2 75 34 c3 48 c7 c7 55 d7 78 82 e8 4e 45 3b 00 0b eb 31 48 c7 c7 27 a8 70 82 e8 3e 45 3b 00 0f 0b eb 21 48 c7<br /> [ 5695.054919] RSP: 0018:ffffc90027aef4f0 EFLAGS: 00010246<br /> [ 5695.065366] RAX: 41fe484987275300 RBX: ffff888008988180 RCX: 0000000000000000<br /> [ 5695.079636] RDX: ffff88886006c280 RSI: ffff888860060480 RDI: ffff888860060480<br /> [ 5695.093904] RBP: 0000000000000002 R08: 0000000000000000 R09: ffffc90027aef370<br /> [ 5695.108175] R10: 0000000000000000 R11: ffffffff82fdf1c0 R12: 0000000010000002<br /> [ 5695.122447] R13: ffff888014b6a448 R14: ffff888014b6a420 R15: 00000000138dc240<br /> [ 5695.136717] FS: 00007f23a7d3f740(0000) GS:ffff888860040000(0000) knlGS:0000000000000000<br /> [ 5695.152899] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5695.164388] CR2: 0000560ceaab6ac0 CR3: 000000001c06c001 CR4: 00000000007706e0<br /> [ 5695.178659] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 5695.192927] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 5695.207197] PKRU: 55555554<br /> [ 5695.212602] Call Trace:<br /> [ 5695.217486] <br /> [ 5695.221674] zs_map_object+0x91/0x270<br /> [ 5695.229000] zswap_frontswap_store+0x33d/0x870<br /> [ 5695.237885] ? do_raw_spin_lock+0x5d/0xa0<br /> [ 5695.245899] __frontswap_store+0x51/0xb0<br /> [ 5695.253742] swap_writepage+0x3c/0x60<br /> [ 5695.261063] shrink_page_list+0x738/0x1230<br /> [ 5695.269255] shrink_lruvec+0x5ec/0xcd0<br /> [ 5695.276749] ? shrink_slab+0x187/0x5f0<br /> [ 5695.284240] ? mem_cgroup_iter+0x6e/0x120<br /> [ 5695.292255] shrink_node+0x293/0x7b0<br /> [ 5695.299402] do_try_to_free_pages+0xea/0x550<br /> [ 5695.307940] try_to_free_pages+0x19a/0x490<br /> [ 5695.316126] __folio_alloc+0x19ff/0x3e40<br /> [ 5695.323971] ? __filemap_get_folio+0x8a/0x4e0<br /> [ 5695.332681] ? walk_component+0x2a8/0xb50<br /> [ 5695.340697] ? generic_permission+0xda/0x2a0<br /> [ 5695.349231] ? __filemap_get_folio+0x8a/0x4e0<br /> [ 5695.357940] ? walk_component+0x2a8/0xb50<br /> [ 5695.365955] vma_alloc_folio+0x10e/0x570<br /> [ 5695.373796] ? walk_component+0x52/0xb50<br /> [ 5695.381634] wp_page_copy+0x38c/0xc10<br /> [ 5695.388953] ? filename_lookup+0x378/0xbc0<br /> [ 5695.397140] handle_mm_fault+0x87f/0x1800<br /> [ 5695.405157] do_user_addr_fault+0x1bd/0x570<br /> [ 5695.413520] exc_page_fault+0x5d/0x110<br /> [ 5695.421017] asm_exc_page_fault+0x22/0x30<br /> <br /> After some investigation, I have found the following issue: unlike other<br /> zswap backends, zsmalloc performs the LRU list update at the object<br /> mapping time, rather than when the slot for the object is allocated.<br /> This deviation was discussed and agreed upon during the review process<br /> of the zsmalloc writeback patch series:<br /> <br /> https://lore.kernel.org/lkml/Y3flcAXNxxrvy3ZH@cmpxchg.org/<br /> <br /> Unfortunately, this introduces a subtle bug that occurs when there is a<br /> concurrent store and reclaim, which interleave as follows:<br /> <br /> zswap_frontswap_store() shrink_worker()<br /> zs_malloc() zs_zpool_shrink()<br /> spin_lock(&amp;pool-&gt;lock) zs_reclaim_page()<br /> zspage = find_get_zspage()<br /> spin_unlock(&amp;pool-&gt;lock)<br /> spin_lock(&amp;pool-&gt;lock)<br /> zspage = list_first_entry(&amp;pool-&gt;lru)<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Fix Kernel Panic during ndo_tx_timeout callback<br /> <br /> The Xeon validation group has been carrying out some loaded tests<br /> with various HW configurations, and they have seen some transmit<br /> queue time out happening during the test. This will cause the<br /> reset adapter function to be called by igc_tx_timeout().<br /> Similar race conditions may arise when the interface is being brought<br /> down and up in igc_reinit_locked(), an interrupt being generated, and<br /> igc_clean_tx_irq() being called to complete the TX.<br /> <br /> When the igc_tx_timeout() function is invoked, this patch will turn<br /> off all TX ring HW queues during igc_down() process. TX ring HW queues<br /> will be activated again during the igc_configure_tx_ring() process<br /> when performing the igc_up() procedure later.<br /> <br /> This patch also moved existing igc_disable_tx_ring_hw() to avoid using<br /> forward declaration.<br /> <br /> Kernel trace:<br /> [ 7678.747813] ------------[ cut here ]------------<br /> [ 7678.757914] NETDEV WATCHDOG: enp1s0 (igc): transmit queue 2 timed out<br /> [ 7678.770117] WARNING: CPU: 0 PID: 13 at net/sched/sch_generic.c:525 dev_watchdog+0x1ae/0x1f0<br /> [ 7678.784459] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE xt_addrtype nft_compat<br /> nf_tables nfnetlink br_netfilter bridge stp llc overlay dm_mod emrcha(PO) emriio(PO) rktpm(PO)<br /> cegbuf_mod(PO) patch_update(PO) se(PO) sgx_tgts(PO) mktme(PO) keylocker(PO) svtdx(PO) svfs_pci_hotplug(PO)<br /> vtd_mod(PO) davemem(PO) svmabort(PO) svindexio(PO) usbx2(PO) ehci_sched(PO) svheartbeat(PO) ioapic(PO)<br /> sv8259(PO) svintr(PO) lt(PO) pcierootport(PO) enginefw_mod(PO) ata(PO) smbus(PO) spiflash_cdf(PO) arden(PO)<br /> dsa_iax(PO) oobmsm_punit(PO) cpm(PO) svkdb(PO) ebg_pch(PO) pch(PO) sviotargets(PO) svbdf(PO) svmem(PO)<br /> svbios(PO) dram(PO) svtsc(PO) targets(PO) superio(PO) svkernel(PO) cswitch(PO) mcf(PO) pentiumIII_mod(PO)<br /> fs_svfs(PO) mdevdefdb(PO) svfs_os_services(O) ixgbe mdio mdio_devres libphy emeraldrapids_svdefs(PO)<br /> regsupport(O) libnvdimm nls_cp437 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel<br /> snd_intel_dspcfg snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core snd_pcm snd_timer isst_if_mbox_pci<br /> [ 7678.784496] input_leds isst_if_mmio sg snd isst_if_common soundcore wmi button sad9(O) drm fuse backlight<br /> configfs efivarfs ip_tables x_tables vmd sdhci led_class rtl8150 r8152 hid_generic pegasus mmc_block usbhid<br /> mmc_core hid megaraid_sas ixgb igb i2c_algo_bit ice i40e hpsa scsi_transport_sas e1000e e1000 e100 ax88179_178a<br /> usbnet xhci_pci sd_mod xhci_hcd t10_pi crc32c_intel crc64_rocksoft igc crc64 crc_t10dif usbcore<br /> crct10dif_generic ptp crct10dif_common usb_common pps_core<br /> [ 7679.200403] RIP: 0010:dev_watchdog+0x1ae/0x1f0<br /> [ 7679.210201] Code: 28 e9 53 ff ff ff 4c 89 e7 c6 05 06 42 b9 00 01 e8 17 d1 fb ff 44 89 e9 4c<br /> 89 e6 48 c7 c7 40 ad fb 81 48 89 c2 e8 52 62 82 ff 0b e9 72 ff ff ff 65 8b 05 80 7d 7c 7e<br /> 89 c0 48 0f a3 05 0a c1<br /> [ 7679.245438] RSP: 0018:ffa00000001f7d90 EFLAGS: 00010282<br /> [ 7679.256021] RAX: 0000000000000000 RBX: ff11000109938440 RCX: 0000000000000000<br /> [ 7679.268710] RDX: ff11000361e26cd8 RSI: ff11000361e1b880 RDI: ff11000361e1b880<br /> [ 7679.281314] RBP: ffa00000001f7da8 R08: ff1100035f8fffe8 R09: 0000000000027ffb<br /> [ 7679.293840] R10: 0000000000001f0a R11: ff1100035f840000 R12: ff11000109938000<br /> [ 7679.306276] R13: 0000000000000002 R14: dead000000000122 R15: ffa00000001f7e18<br /> [ 7679.318648] FS: 0000000000000000(0000) GS:ff11000361e00000(0000) knlGS:0000000000000000<br /> [ 7679.332064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7679.342757] CR2: 00007ffff7fca168 CR3: 000000013b08a006 CR4: 0000000000471ef8<br /> [ 7679.354984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 7679.367207] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 7679.379370] PKRU: 55555554<br /> [ 7679.386446] Call Trace:<br /> [ 7679.393152] <br /> [ 7679.399363] ? __pfx_dev_watchdog+0x10/0x10<br /> [ 7679.407870] call_timer_fn+0x31/0x110<br /> [ 7679.415698] e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: mm: Move initrd phys_to_virt handling after paging_init()<br /> <br /> When booting with an initial ramdisk on platforms where physical memory<br /> does not start at address zero (e.g. on Amiga):<br /> <br /> initrd: 0ef0602c - 0f800000<br /> Zone ranges:<br /> DMA [mem 0x0000000008000000-0x000000f7ffffffff]<br /> Normal empty<br /> Movable zone start for each node<br /> Early memory node ranges<br /> node 0: [mem 0x0000000008000000-0x000000000f7fffff]<br /> Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]<br /> Unable to handle kernel access at virtual address (ptrval)<br /> Oops: 00000000<br /> Modules linked in:<br /> PC: [] memcmp+0x28/0x56<br /> <br /> As phys_to_virt() relies on m68k_memoffset and module_fixup(), it must<br /> not be called before paging_init(). Hence postpone the phys_to_virt<br /> handling for the initial ramdisk until after calling paging_init().<br /> <br /> While at it, reduce #ifdef clutter by using IS_ENABLED() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()<br /> <br /> The ucmd-&gt;log_sq_bb_count variable is controlled by the user so this<br /> shift can wrap. Fix it by using check_shl_overflow() in the same way<br /> that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined<br /> behavior in hns_roce_set_user_sq_size()").