Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Handle kstrdup failures for passwords<br /> <br /> In smb3_reconfigure(), after duplicating ctx-&gt;password and<br /> ctx-&gt;password2 with kstrdup(), we need to check for allocation<br /> failures.<br /> <br /> If ses-&gt;password allocation fails, return -ENOMEM.<br /> If ses-&gt;password2 allocation fails, free ses-&gt;password, set it<br /> to NULL, and return -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net<br /> <br /> In the normal case, when we excute `echo 0 &gt; /proc/fs/nfsd/threads`, the<br /> function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will<br /> release all resources related to the hashed `nfs4_client`. If the<br /> `nfsd_client_shrinker` is running concurrently, the `expire_client`<br /> function will first unhash this client and then destroy it. This can<br /> lead to the following warning. Additionally, numerous use-after-free<br /> errors may occur as well.<br /> <br /> nfsd_client_shrinker echo 0 &gt; /proc/fs/nfsd/threads<br /> <br /> expire_client nfsd_shutdown_net<br /> unhash_client ...<br /> nfs4_state_shutdown_net<br /> /* won&amp;#39;t wait shrinker exit */<br /> /* cancel_work(&amp;nn-&gt;nfsd_shrinker_work)<br /> * nfsd_file for this /* won&amp;#39;t destroy unhashed client1 */<br /> * client1 still alive nfs4_state_destroy_net<br /> */<br /> <br /> nfsd_file_cache_shutdown<br /> /* trigger warning */<br /> kmem_cache_destroy(nfsd_file_slab)<br /> kmem_cache_destroy(nfsd_file_mark_slab)<br /> /* release nfsd_file and mark */<br /> __destroy_client<br /> <br /> ====================================================================<br /> BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on<br /> __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xac/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ====================================================================<br /> BUG nfsd_file_mark (Tainted: G B W ): Objects remaining<br /> nfsd_file_mark on __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xc8/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> To resolve this issue, cancel `nfsd_shrinker_work` using synchronous<br /> mode in nfs4_state_shutdown_net.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Fix UAF on iso_sock_timeout<br /> <br /> conn-&gt;sk maybe have been unlinked/freed while waiting for iso_conn_lock<br /> so this checks if the conn-&gt;sk is still valid by checking if it part of<br /> iso_sk_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: Fix UAF on sco_sock_timeout<br /> <br /> conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock<br /> so this checks if the conn-&gt;sk is still valid by checking if it part of<br /> sco_sk_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: use RCU read-side critical section in taprio_dump()<br /> <br /> Fix possible use-after-free in &amp;#39;taprio_dump()&amp;#39; by adding RCU<br /> read-side critical section there. Never seen on x86 but<br /> found on a KASAN-enabled arm64 system when investigating<br /> https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa:<br /> <br /> [T15862] BUG: KASAN: slab-use-after-free in taprio_dump+0xa0c/0xbb0<br /> [T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862<br /> [T15862]<br /> [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2<br /> [T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024<br /> [T15862] Call trace:<br /> [T15862] dump_backtrace+0x20c/0x220<br /> [T15862] show_stack+0x2c/0x40<br /> [T15862] dump_stack_lvl+0xf8/0x174<br /> [T15862] print_report+0x170/0x4d8<br /> [T15862] kasan_report+0xb8/0x1d4<br /> [T15862] __asan_report_load4_noabort+0x20/0x2c<br /> [T15862] taprio_dump+0xa0c/0xbb0<br /> [T15862] tc_fill_qdisc+0x540/0x1020<br /> [T15862] qdisc_notify.isra.0+0x330/0x3a0<br /> [T15862] tc_modify_qdisc+0x7b8/0x1838<br /> [T15862] rtnetlink_rcv_msg+0x3c8/0xc20<br /> [T15862] netlink_rcv_skb+0x1f8/0x3d4<br /> [T15862] rtnetlink_rcv+0x28/0x40<br /> [T15862] netlink_unicast+0x51c/0x790<br /> [T15862] netlink_sendmsg+0x79c/0xc20<br /> [T15862] __sock_sendmsg+0xe0/0x1a0<br /> [T15862] ____sys_sendmsg+0x6c0/0x840<br /> [T15862] ___sys_sendmsg+0x1ac/0x1f0<br /> [T15862] __sys_sendmsg+0x110/0x1d0<br /> [T15862] __arm64_sys_sendmsg+0x74/0xb0<br /> [T15862] invoke_syscall+0x88/0x2e0<br /> [T15862] el0_svc_common.constprop.0+0xe4/0x2a0<br /> [T15862] do_el0_svc+0x44/0x60<br /> [T15862] el0_svc+0x50/0x184<br /> [T15862] el0t_64_sync_handler+0x120/0x12c<br /> [T15862] el0t_64_sync+0x190/0x194<br /> [T15862]<br /> [T15862] Allocated by task 15857:<br /> [T15862] kasan_save_stack+0x3c/0x70<br /> [T15862] kasan_save_track+0x20/0x3c<br /> [T15862] kasan_save_alloc_info+0x40/0x60<br /> [T15862] __kasan_kmalloc+0xd4/0xe0<br /> [T15862] __kmalloc_cache_noprof+0x194/0x334<br /> [T15862] taprio_change+0x45c/0x2fe0<br /> [T15862] tc_modify_qdisc+0x6a8/0x1838<br /> [T15862] rtnetlink_rcv_msg+0x3c8/0xc20<br /> [T15862] netlink_rcv_skb+0x1f8/0x3d4<br /> [T15862] rtnetlink_rcv+0x28/0x40<br /> [T15862] netlink_unicast+0x51c/0x790<br /> [T15862] netlink_sendmsg+0x79c/0xc20<br /> [T15862] __sock_sendmsg+0xe0/0x1a0<br /> [T15862] ____sys_sendmsg+0x6c0/0x840<br /> [T15862] ___sys_sendmsg+0x1ac/0x1f0<br /> [T15862] __sys_sendmsg+0x110/0x1d0<br /> [T15862] __arm64_sys_sendmsg+0x74/0xb0<br /> [T15862] invoke_syscall+0x88/0x2e0<br /> [T15862] el0_svc_common.constprop.0+0xe4/0x2a0<br /> [T15862] do_el0_svc+0x44/0x60<br /> [T15862] el0_svc+0x50/0x184<br /> [T15862] el0t_64_sync_handler+0x120/0x12c<br /> [T15862] el0t_64_sync+0x190/0x194<br /> [T15862]<br /> [T15862] Freed by task 6192:<br /> [T15862] kasan_save_stack+0x3c/0x70<br /> [T15862] kasan_save_track+0x20/0x3c<br /> [T15862] kasan_save_free_info+0x4c/0x80<br /> [T15862] poison_slab_object+0x110/0x160<br /> [T15862] __kasan_slab_free+0x3c/0x74<br /> [T15862] kfree+0x134/0x3c0<br /> [T15862] taprio_free_sched_cb+0x18c/0x220<br /> [T15862] rcu_core+0x920/0x1b7c<br /> [T15862] rcu_core_si+0x10/0x1c<br /> [T15862] handle_softirqs+0x2e8/0xd64<br /> [T15862] __do_softirq+0x14/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix use-after-free in taprio_change()<br /> <br /> In &amp;#39;taprio_change()&amp;#39;, &amp;#39;admin&amp;#39; pointer may become dangling due to sched<br /> switch / removal caused by &amp;#39;advance_sched()&amp;#39;, and critical section<br /> protected by &amp;#39;q-&gt;current_entry_lock&amp;#39; is too small to prevent from such<br /> a scenario (which causes use-after-free detected by KASAN). Fix this<br /> by prefer &amp;#39;rcu_replace_pointer()&amp;#39; over &amp;#39;rcu_assign_pointer()&amp;#39; to update<br /> &amp;#39;admin&amp;#39; immediately before an attempt to schedule freeing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: fix global oob in wwan_rtnl_policy<br /> <br /> The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to<br /> a global out-of-bounds read when parsing the netlink attributes. Exactly<br /> same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm:<br /> rmnet: fix global oob in rmnet_policy").<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline]<br /> BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603<br /> Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862<br /> <br /> CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x14f/0x750 mm/kasan/report.c:395<br /> kasan_report+0x139/0x170 mm/kasan/report.c:495<br /> validate_nla lib/nlattr.c:388 [inline]<br /> __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603<br /> __nla_parse+0x3c/0x50 lib/nlattr.c:700<br /> nla_parse_nested_deprecated include/net/netlink.h:1269 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3514 [inline]<br /> rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623<br /> rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122<br /> netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]<br /> netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352<br /> netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874<br /> sock_sendmsg_nosec net/socket.c:716 [inline]<br /> __sock_sendmsg net/socket.c:728 [inline]<br /> ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499<br /> ___sys_sendmsg+0x21c/0x290 net/socket.c:2553<br /> __sys_sendmsg net/socket.c:2582 [inline]<br /> __do_sys_sendmsg net/socket.c:2591 [inline]<br /> __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f67b19a24ad<br /> RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad<br /> RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004<br /> RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40<br /> <br /> <br /> The buggy address belongs to the variable:<br /> wwan_rtnl_policy+0x20/0x40<br /> <br /> The buggy address belongs to the physical page:<br /> page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c<br /> flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner info is not present (never set?)<br /> <br /> Memory state around the buggy address:<br /> ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9<br /> ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9<br /> &gt;ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9<br /> ^<br /> ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ==================================================================<br /> <br /> According to the comment of `nla_parse_nested_deprecated`, use correct size<br /> `IFLA_WWAN_MAX` here to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Consider the NULL character when validating the event length<br /> <br /> strlen() returns a string length excluding the null byte. If the string<br /> length equals to the maximum buffer length, the buffer will have no<br /> space for the NULL terminating character.<br /> <br /> This commit checks this condition and returns failure for it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc<br /> <br /> Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to<br /> soundcards") moved the allocation of Soundwire stream runtime from the<br /> Qualcomm Soundwire driver to each individual machine sound card driver,<br /> except that it forgot to update SC7280 card.<br /> <br /> Just like for other Qualcomm sound cards using Soundwire, the card<br /> driver should allocate and release the runtime. Otherwise sound<br /> playback will result in a NULL pointer dereference or other effect of<br /> uninitialized memory accesses (which was confirmed on SDM845 having<br /> similar issue).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix race between laundromat and free_stateid<br /> <br /> There is a race between laundromat handling of revoked delegations<br /> and a client sending free_stateid operation. Laundromat thread<br /> finds that delegation has expired and needs to be revoked so it<br /> marks the delegation stid revoked and it puts it on a reaper list<br /> but then it unlock the state lock and the actual delegation revocation<br /> happens without the lock. Once the stid is marked revoked a racing<br /> free_stateid processing thread does the following (1) it calls<br /> list_del_init() which removes it from the reaper list and (2) frees<br /> the delegation stid structure. The laundromat thread ends up not<br /> calling the revoke_delegation() function for this particular delegation<br /> but that means it will no release the lock lease that exists on<br /> the file.<br /> <br /> Now, a new open for this file comes in and ends up finding that<br /> lease list isn&amp;#39;t empty and calls nfsd_breaker_owns_lease() which ends<br /> up trying to derefence a freed delegation stateid. Leading to the<br /> followint use-after-free KASAN warning:<br /> <br /> kernel: ==================================================================<br /> kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]<br /> kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205<br /> kernel:<br /> kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9<br /> kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024<br /> kernel: Call trace:<br /> kernel: dump_backtrace+0x98/0x120<br /> kernel: show_stack+0x1c/0x30<br /> kernel: dump_stack_lvl+0x80/0xe8<br /> kernel: print_address_description.constprop.0+0x84/0x390<br /> kernel: print_report+0xa4/0x268<br /> kernel: kasan_report+0xb4/0xf8<br /> kernel: __asan_report_load8_noabort+0x1c/0x28<br /> kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]<br /> kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]<br /> kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]<br /> kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]<br /> kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]<br /> kernel: nfsd4_open+0xa08/0xe80 [nfsd]<br /> kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]<br /> kernel: nfsd_dispatch+0x22c/0x718 [nfsd]<br /> kernel: svc_process_common+0x8e8/0x1960 [sunrpc]<br /> kernel: svc_process+0x3d4/0x7e0 [sunrpc]<br /> kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]<br /> kernel: svc_recv+0x2cc/0x6a8 [sunrpc]<br /> kernel: nfsd+0x270/0x400 [nfsd]<br /> kernel: kthread+0x288/0x310<br /> kernel: ret_from_fork+0x10/0x20<br /> <br /> This patch proposes a fixed that&amp;#39;s based on adding 2 new additional<br /> stid&amp;#39;s sc_status values that help coordinate between the laundromat<br /> and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).<br /> <br /> First to make sure, that once the stid is marked revoked, it is not<br /> removed by the nfsd4_free_stateid(), the laundromat take a reference<br /> on the stateid. Then, coordinating whether the stid has been put<br /> on the cl_revoked list or we are processing FREE_STATEID and need to<br /> make sure to remove it from the list, each check that state and act<br /> accordingly. If laundromat has added to the cl_revoke list before<br /> the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove<br /> it from the list. If nfsd4_free_stateid() finds that operations arrived<br /> before laundromat has placed it on cl_revoke list, it marks the state<br /> freed and then laundromat will no longer add it to the list.<br /> <br /> Also, for nfsd4_delegreturn() when looking for the specified stid,<br /> we need to access stid that are marked removed or freeable, it means<br /> the laundromat has started processing it but hasn&amp;#39;t finished and this<br /> delegreturn needs to return nfserr_deleg_revoked and not<br /> nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the<br /> lack of it will leave this stid on the cl_revoked list indefinitely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid addresses<br /> <br /> Commit 50c6dbdfd16e ("x86/ioremap: Improve iounmap() address range checks")<br /> introduces a WARN when adrress ranges of iounmap are invalid. On Thinkpad<br /> P1 Gen 7 (Meteor Lake-P) this caused the following warning to appear:<br /> <br /> WARNING: CPU: 7 PID: 713 at arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0<br /> Modules linked in: rfkill(+) snd_timer(+) fjes(+) snd soundcore intel_pmc_core(+)<br /> int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad pmt_class<br /> acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper<br /> nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit<br /> crct10dif_pclmul crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi<br /> polyval_generic mmc_core hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi<br /> nvme sha512_ssse3 video sha256_ssse3 nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec<br /> nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake serio_raw ip6_tables ip_tables fuse<br /> CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted 6.12.0-rc2iounmap+ #42<br /> Hardware name: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06 ) 07/18/2024<br /> RIP: 0010:iounmap+0x58/0x1f0<br /> Code: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00<br /> RSP: 0018:ffff888131eff038 EFLAGS: 00010207<br /> RAX: ffffc90000000000 RBX: 0000000000000000 RCX: ffff888e33b80000<br /> RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10<br /> R10: 0000000000000003 R11: ffffffffb3367634 R12: 00000000fe000000<br /> R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28<br /> FS: 00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn.cold+0xb6/0x176<br /> ? iounmap+0x58/0x1f0<br /> ? report_bug+0x1f4/0x2b0<br /> ? handle_bug+0x58/0x90<br /> ? exc_invalid_op+0x17/0x40<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? iounmap+0x58/0x1f0<br /> pmc_core_ssram_get_pmc+0x477/0x6c0 [intel_pmc_core]<br /> ? __pfx_pmc_core_ssram_get_pmc+0x10/0x10 [intel_pmc_core]<br /> ? __pfx_do_pci_enable_device+0x10/0x10<br /> ? pci_wait_for_pending+0x60/0x110<br /> ? pci_enable_device_flags+0x1e3/0x2e0<br /> ? __pfx_mtl_core_init+0x10/0x10 [intel_pmc_core]<br /> pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core]<br /> mtl_core_init+0xda/0x130 [intel_pmc_core]<br /> ? __mutex_init+0xb9/0x130<br /> pmc_core_probe+0x27e/0x10b0 [intel_pmc_core]<br /> ? _raw_spin_lock_irqsave+0x96/0xf0<br /> ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core]<br /> ? __pfx_mutex_unlock+0x10/0x10<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ? device_pm_check_callbacks+0x82/0x370<br /> ? acpi_dev_pm_attach+0x234/0x2b0<br /> platform_probe+0x9f/0x150<br /> really_probe+0x1e0/0x8a0<br /> __driver_probe_device+0x18c/0x370<br /> ? __pfx___driver_attach+0x10/0x10<br /> driver_probe_device+0x4a/0x120<br /> __driver_attach+0x190/0x4a0<br /> ? __pfx___driver_attach+0x10/0x10<br /> bus_for_each_dev+0x103/0x180<br /> ? __pfx_bus_for_each_dev+0x10/0x10<br /> ? klist_add_tail+0x136/0x270<br /> bus_add_driver+0x2fc/0x540<br /> driver_register+0x1a5/0x360<br /> ? __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core]<br /> do_one_initcall+0xa4/0x380<br /> ? __pfx_do_one_initcall+0x10/0x10<br /> ? kasan_unpoison+0x44/0x70<br /> do_init_module+0x296/0x800<br /> load_module+0x5090/0x6ce0<br /> ? __pfx_load_module+0x10/0x10<br /> ? ima_post_read_file+0x193/0x200<br /> ? __pfx_ima_post_read_file+0x10/0x10<br /> ? rw_verify_area+0x152/0x4c0<br /> ? kernel_read_file+0x257/0x750<br /> ? __pfx_kernel_read_file+0x10/0x10<br /> ? __pfx_filemap_get_read_batch+0x10/0x10<br /> ? init_module_from_file+0xd1/0x130<br /> init_module_from_file+0xd1/0x130<br /> ? __pfx_init_module_from_file+0x10/0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix null ptr dereference in raid10_size()<br /> <br /> In raid10_run() if raid10_set_queue_limits() succeed, the return value<br /> is set to zero, and if following procedures failed raid10_run() will<br /> return zero while mddev-&gt;private is still NULL, causing null ptr<br /> dereference in raid10_size().<br /> <br /> Fix the problem by only overwrite the return value if<br /> raid10_set_queue_limits() failed.