Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix system suspend without fbdev being initialized<br /> <br /> If fbdev is not initialized for some reason - in practice on platforms<br /> without display - suspending fbdev should be skipped during system<br /> suspend, fix this up. While at it add an assert that suspending fbdev<br /> only happens with the display present.<br /> <br /> This fixes the following:<br /> <br /> [ 91.227923] PM: suspend entry (s2idle)<br /> [ 91.254598] Filesystems sync: 0.025 seconds<br /> [ 91.270518] Freezing user space processes<br /> [ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds)<br /> [ 91.272686] OOM killer disabled.<br /> [ 91.272872] Freezing remaining freezable tasks<br /> [ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)<br /> [ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8<br /> [ 91.659981] #PF: supervisor write access in kernel mode<br /> [ 91.660252] #PF: error_code(0x0002) - not-present page<br /> [ 91.660511] PGD 0 P4D 0<br /> [ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54<br /> [ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown<br /> [ 91.661680] RIP: 0010:mutex_lock+0x19/0x30<br /> [ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40<br /> [ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246<br /> [ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000<br /> [ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8<br /> [ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0<br /> [ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20<br /> [ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000<br /> [ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0<br /> [ 91.665988] PKRU: 55555554<br /> [ 91.666131] Call Trace:<br /> [ 91.666265] <br /> [ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915]<br /> [ 91.666738] i915_drm_suspend+0xb9/0x100 [i915]<br /> [ 91.667029] pci_pm_suspend+0x78/0x170<br /> [ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10<br /> [ 91.667461] dpm_run_callback+0x47/0x150<br /> [ 91.667673] __device_suspend+0x10a/0x4e0<br /> [ 91.667880] dpm_suspend+0x134/0x270<br /> [ 91.668069] dpm_suspend_start+0x79/0x80<br /> [ 91.668272] suspend_devices_and_enter+0x11b/0x890<br /> [ 91.668526] pm_suspend.cold+0x270/0x2fc<br /> [ 91.668737] state_store+0x46/0x90<br /> [ 91.668916] kernfs_fop_write_iter+0x11b/0x200<br /> [ 91.669153] vfs_write+0x1e1/0x3a0<br /> [ 91.669336] ksys_write+0x53/0xd0<br /> [ 91.669510] do_syscall_64+0x58/0xc0<br /> [ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0<br /> [ 91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0<br /> [ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40<br /> [ 91.670524] ? do_syscall_64+0x67/0xc0<br /> [ 91.670717] ? __irq_exit_rcu+0x3d/0x140<br /> [ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [ 91.671202] RIP: 0033:0x7f28ffd14284<br /> <br /> v2: CC stable. (Jani)<br /> <br /> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015<br /> (cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: output extra debug info if we failed to find an inline backref<br /> <br /> [BUG]<br /> Syzbot reported several warning triggered inside<br /> lookup_inline_extent_backref().<br /> <br /> [CAUSE]<br /> As usual, the reproducer doesn&amp;#39;t reliably trigger locally here, but at<br /> least we know the WARN_ON() is triggered when an inline backref can not<br /> be found, and it can only be triggered when @insert is true. (I.e.<br /> inserting a new inline backref, which means the backref should already<br /> exist)<br /> <br /> [ENHANCEMENT]<br /> After the WARN_ON(), dump all the parameters and the extent tree<br /> leaf to help debug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL<br /> <br /> Commit 994f706872e6 ("srcu: Make Tree SRCU able to operate without<br /> snp_node array") assumes that cpu 0 is always online. However, there<br /> really are situations when some other CPU is the boot CPU, for example,<br /> when booting a kdump kernel with the maxcpus=1 boot parameter.<br /> <br /> On PowerPC, the kdump kernel can hang as follows:<br /> ...<br /> [ 1.740036] systemd[1]: Hostname set to <br /> [ 243.686240] INFO: task systemd:1 blocked for more than 122 seconds.<br /> [ 243.686264] Not tainted 6.1.0-rc1 #1<br /> [ 243.686272] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000<br /> [ 243.686296] Call Trace:<br /> [ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable)<br /> [ 243.686317] [c000000016657830] [c00000001001dec0] __switch_to+0x130/0x220<br /> [ 243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580<br /> [ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140<br /> [ 243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+0x168/0x1c0<br /> [ 243.686374] [c000000016657a80] [c000000010f61de8] __wait_for_common+0x148/0x360<br /> [ 243.686387] [c000000016657b20] [c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0<br /> [ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40<br /> [ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160<br /> [ 243.686428] [c000000016657c40] [c0000000105f6500] inotify_release+0x30/0xa0<br /> [ 243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350<br /> [ 243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170<br /> [ 243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140<br /> [ 243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270<br /> [ 243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180<br /> [ 243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280<br /> [ 243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4<br /> [ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000<br /> [ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1)<br /> [ 243.686548] MSR: 800000000000d033 CR: 42044440 XER: 00000000<br /> [ 243.686572] IRQMASK: 0<br /> [ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000<br /> [ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001<br /> [ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000<br /> [ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000<br /> [ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000<br /> [ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570<br /> [ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98<br /> [ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4<br /> [ 243.686691] LR [0000000000000000] 0x0<br /> [ 243.686698] --- interrupt: 3000<br /> [ 243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.<br /> [ 243.686717] Not tainted 6.1.0-rc1 #1<br /> [ 243.686724] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800<br /> [ 243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn<br /> [ 243.686758] Call Trace:<br /> [ 243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable)<br /> [ 243.686775] [c0000000166738d0] [c00000001001dec0] __switch_to+0x130/0x220<br /> [ 243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix memory leaks in i915 selftests<br /> <br /> This patch fixes memory leaks on error escapes in function fake_get_pages<br /> <br /> (cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()<br /> <br /> The function lio_target_nacl_info_show() uses sprintf() in a loop to print<br /> details for every iSCSI connection in a session without checking for the<br /> buffer length. With enough iSCSI connections it&amp;#39;s possible to overflow the<br /> buffer provided by configfs and corrupt the memory.<br /> <br /> This patch replaces sprintf() with sysfs_emit_at() that checks for buffer<br /> boundries.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Fix possible desc_ptr out-of-bounds accesses<br /> <br /> Sanitize possible desc_ptr out-of-bounds accesses in<br /> ses_enclosure_data_process().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Fix memory leak in devm_clk_notifier_register()<br /> <br /> devm_clk_notifier_register() allocates a devres resource for clk<br /> notifier but didn&amp;#39;t register that to the device, so the notifier didn&amp;#39;t<br /> get unregistered on device detach and the allocated resource was leaked.<br /> <br /> Fix the issue by registering the resource through devres_add().<br /> <br /> This issue was found with kmemleak on a Chromebook.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: call disconnect callback before deleting conn<br /> <br /> In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.<br /> <br /> ISO, L2CAP and SCO connections refer to the hci_conn without<br /> hci_conn_get, so disconn_cfm must be called so they can clean up their<br /> conn, otherwise use-after-free occurs.<br /> <br /> ISO:<br /> ==========================================================<br /> iso_sock_connect:880: sk 00000000eabd6557<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 000000001696f1fd conn 00000000b6251073<br /> hci_dev_put:1487: hci0 orig refcnt 17<br /> __iso_chan_add:214: conn 00000000b6251073<br /> iso_sock_clear_timer:117: sock 00000000eabd6557 state 3<br /> ...<br /> hci_rx_work:4085: hci0 Event packet<br /> hci_event_packet:7601: hci0: event 0x0f<br /> hci_cmd_status_evt:4346: hci0: opcode 0x0406<br /> hci_cs_disconnect:2760: hci0: status 0x0c<br /> hci_sent_cmd_data:3107: hci0 opcode 0x0406<br /> hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560<br /> hci_conn_unlink:1102: hci0: hcon 000000001696f1fd<br /> hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2<br /> hci_chan_list_flush:2780: hcon 000000001696f1fd<br /> hci_dev_put:1487: hci0 orig refcnt 21<br /> hci_dev_put:1487: hci0 orig refcnt 20<br /> hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c<br /> ... ...<br /> iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557<br /> BUG: kernel NULL pointer dereference, address: 0000000000000668<br /> PGD 0 P4D 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_sendmsg (net/bluetooth/iso.c:1112) bluetooth<br /> ==========================================================<br /> <br /> L2CAP:<br /> ==================================================================<br /> hci_cmd_status_evt:4359: hci0: opcode 0x0406<br /> hci_cs_disconnect:2760: hci0: status 0x0c<br /> hci_sent_cmd_data:3085: hci0 opcode 0x0406<br /> hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585<br /> hci_conn_unlink:1102: hci0: hcon ffff88800c999000<br /> hci_chan_list_flush:2780: hcon ffff88800c999000<br /> hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280<br /> ...<br /> BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]<br /> Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175<br /> <br /> CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x90<br /> print_report+0xcf/0x670<br /> ? __virt_addr_valid+0xf8/0x180<br /> ? hci_send_acl+0x2d/0x540 [bluetooth]<br /> kasan_report+0xa8/0xe0<br /> ? hci_send_acl+0x2d/0x540 [bluetooth]<br /> hci_send_acl+0x2d/0x540 [bluetooth]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> l2cap_chan_send+0x1fd/0x1300 [bluetooth]<br /> ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]<br /> ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]<br /> ? lock_release+0x1d5/0x3c0<br /> ? mark_held_locks+0x1a/0x90<br /> l2cap_sock_sendmsg+0x100/0x170 [bluetooth]<br /> sock_write_iter+0x275/0x280<br /> ? __pfx_sock_write_iter+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> do_iter_readv_writev+0x176/0x220<br /> ? __pfx_do_iter_readv_writev+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? selinux_file_permission+0x13e/0x210<br /> do_iter_write+0xda/0x340<br /> vfs_writev+0x1b4/0x400<br /> ? __pfx_vfs_writev+0x10/0x10<br /> ? __seccomp_filter+0x112/0x750<br /> ? populate_seccomp_data+0x182/0x220<br /> ? __fget_light+0xdf/0x100<br /> ? do_writev+0x19d/0x210<br /> do_writev+0x19d/0x210<br /> ? __pfx_do_writev+0x10/0x10<br /> ? mark_held_locks+0x1a/0x90<br /> do_syscall_64+0x60/0x90<br /> ? lockdep_hardirqs_on_prepare+0x149/0x210<br /> ? do_syscall_64+0x6c/0x90<br /> ? lockdep_hardirqs_on_prepare+0x149/0x210<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7ff45cb23e64<br /> Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89<br /> RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014<br /> RAX: ffffffffffffffda RBX: <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()<br /> <br /> "opp" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by<br /> removing the dereference to cache opp_table and dereference it directly<br /> where opp_table is used.<br /> <br /> This fixes the following smatch warning:<br /> <br /> drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable<br /> dereferenced before IS_ERR check &amp;#39;opp&amp;#39; (see line 230)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Check instead of asserting on nested TSC scaling support<br /> <br /> Check for nested TSC scaling support on nested SVM VMRUN instead of<br /> asserting that TSC scaling is exposed to L1 if L1&amp;#39;s MSR_AMD64_TSC_RATIO<br /> has diverged from KVM&amp;#39;s default. Userspace can trigger the WARN at will<br /> by writing the MSR and then updating guest CPUID to hide the feature<br /> (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking<br /> KVM&amp;#39;s state_test selftest to do<br /> <br /> vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);<br /> vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);<br /> <br /> after restoring state in a new VM+vCPU yields an endless supply of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699<br /> nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]<br /> Call Trace:<br /> <br /> enter_svm_guest_mode+0x114/0x560 [kvm_amd]<br /> nested_svm_vmrun+0x260/0x330 [kvm_amd]<br /> vmrun_interception+0x29/0x30 [kvm_amd]<br /> svm_invoke_exit_handler+0x35/0x100 [kvm_amd]<br /> svm_handle_exit+0xe7/0x180 [kvm_amd]<br /> kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]<br /> kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]<br /> __se_sys_ioctl+0x7a/0xc0<br /> __x64_sys_ioctl+0x21/0x30<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x45ca1b<br /> <br /> Note, the nested #VMEXIT path has the same flaw, but needs a different<br /> fix and will be handled separately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: don&amp;#39;t dereference mddev after export_rdev()<br /> <br /> Except for initial reference, mddev-&gt;kobject is referenced by<br /> rdev-&gt;kobject, and if the last rdev is freed, there is no guarantee that<br /> mddev is still valid. Hence mddev should not be used anymore after<br /> export_rdev().<br /> <br /> This problem can be triggered by following test for mdadm at very<br /> low rate:<br /> <br /> New file: mdadm/tests/23rdev-lifetime<br /> <br /> devname=${dev0##*/}<br /> devt=`cat /sys/block/$devname/dev`<br /> pid=""<br /> runtime=2<br /> <br /> clean_up_test() {<br /> pill -9 $pid<br /> echo clear &gt; /sys/block/md0/md/array_state<br /> }<br /> <br /> trap &amp;#39;clean_up_test&amp;#39; EXIT<br /> <br /> add_by_sysfs() {<br /> while true; do<br /> echo $devt &gt; /sys/block/md0/md/new_dev<br /> done<br /> }<br /> <br /> remove_by_sysfs(){<br /> while true; do<br /> echo remove &gt; /sys/block/md0/md/dev-${devname}/state<br /> done<br /> }<br /> <br /> echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"<br /> <br /> add_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> remove_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> sleep $runtime<br /> exit 0<br /> <br /> Test cmd:<br /> <br /> ./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime<br /> <br /> Test result:<br /> <br /> general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP<br /> CPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562<br /> RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]<br /> Call Trace:<br /> <br /> mddev_unlock+0x1b6/0x310 [md_mod]<br /> rdev_attr_store+0xec/0x190 [md_mod]<br /> sysfs_kf_write+0x52/0x70<br /> kernfs_fop_write_iter+0x19a/0x2a0<br /> vfs_write+0x3b5/0x770<br /> ksys_write+0x74/0x150<br /> __x64_sys_write+0x22/0x30<br /> do_syscall_64+0x40/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Fix this problem by don&amp;#39;t dereference mddev after export_rdev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd938x: fix missing mbhc init error handling<br /> <br /> MBHC initialisation can fail so add the missing error handling to avoid<br /> dereferencing an error pointer when later configuring the jack:<br /> <br /> Unable to handle kernel paging request at virtual address fffffffffffffff8<br /> <br /> pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]<br /> lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]<br /> <br /> Call trace:<br /> wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]<br /> wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]<br /> snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]<br /> qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]<br /> sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]<br /> snd_soc_link_init+0x28/0x90 [snd_soc_core]<br /> snd_soc_bind_card+0x628/0xbfc [snd_soc_core]<br /> snd_soc_register_card+0xec/0x104 [snd_soc_core]<br /> devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]<br /> sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]