Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: bus: verify partner exists in typec_altmode_attention<br /> <br /> Some usb hubs will negotiate DisplayPort Alt mode with the device<br /> but will then negotiate a data role swap after entering the alt<br /> mode. The data role swap causes the device to unregister all alt<br /> modes, however the usb hub will still send Attention messages<br /> even after failing to reregister the Alt Mode. type_altmode_attention<br /> currently does not verify whether or not a device&amp;#39;s altmode partner<br /> exists, which results in a NULL pointer error when dereferencing<br /> the typec_altmode and typec_altmode_ops belonging to the altmode<br /> partner.<br /> <br /> Verify the presence of a device&amp;#39;s altmode partner before sending<br /> the Attention message to the Alt Mode driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx<br /> <br /> For the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoid<br /> uninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() should<br /> validate pkt_len before accessing the SKB.<br /> <br /> For example, the obtained SKB may have been badly constructed with<br /> pkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdr<br /> but after being processed in ath9k_htc_rx_msg() and passed to<br /> ath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMI<br /> command header which should be located inside its data payload.<br /> <br /> Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninit<br /> memory can be referenced.<br /> <br /> Tested on Qualcomm Atheros Communications AR9271 802.11n .<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_bcm7271: fix leak in `brcmuart_probe`<br /> <br /> Smatch reports:<br /> drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() warn:<br /> &amp;#39;baud_mux_clk&amp;#39; from clk_prepare_enable() not released on lines: 1032.<br /> <br /> The issue is fixed by using a managed clock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix data race on CQP completion stats<br /> <br /> CQP completion statistics is read lockesly in irdma_wait_event and<br /> irdma_check_cqp_progress while it can be updated in the completion<br /> thread irdma_sc_ccq_get_cqe_info on another CPU as KCSAN reports.<br /> <br /> Make completion statistics an atomic variable to reflect coherent updates<br /> to it. This will also avoid load/store tearing logic bug potentially<br /> possible by compiler optimizations.<br /> <br /> [77346.170861] BUG: KCSAN: data-race in irdma_handle_cqp_op [irdma] / irdma_sc_ccq_get_cqe_info [irdma]<br /> <br /> [77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4:<br /> [77346.171483] irdma_sc_ccq_get_cqe_info+0x27a/0x370 [irdma]<br /> [77346.171658] irdma_cqp_ce_handler+0x164/0x270 [irdma]<br /> [77346.171835] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [77346.172009] process_one_work+0x4d1/0xa40<br /> [77346.172024] worker_thread+0x319/0x700<br /> [77346.172037] kthread+0x180/0x1b0<br /> [77346.172054] ret_from_fork+0x22/0x30<br /> <br /> [77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2:<br /> [77346.172234] irdma_handle_cqp_op+0xf4/0x4b0 [irdma]<br /> [77346.172413] irdma_cqp_aeq_cmd+0x75/0xa0 [irdma]<br /> [77346.172592] irdma_create_aeq+0x390/0x45a [irdma]<br /> [77346.172769] irdma_rt_init_hw.cold+0x212/0x85d [irdma]<br /> [77346.172944] irdma_probe+0x54f/0x620 [irdma]<br /> [77346.173122] auxiliary_bus_probe+0x66/0xa0<br /> [77346.173137] really_probe+0x140/0x540<br /> [77346.173154] __driver_probe_device+0xc7/0x220<br /> [77346.173173] driver_probe_device+0x5f/0x140<br /> [77346.173190] __driver_attach+0xf0/0x2c0<br /> [77346.173208] bus_for_each_dev+0xa8/0xf0<br /> [77346.173225] driver_attach+0x29/0x30<br /> [77346.173240] bus_add_driver+0x29c/0x2f0<br /> [77346.173255] driver_register+0x10f/0x1a0<br /> [77346.173272] __auxiliary_driver_register+0xbc/0x140<br /> [77346.173287] irdma_init_module+0x55/0x1000 [irdma]<br /> [77346.173460] do_one_initcall+0x7d/0x410<br /> [77346.173475] do_init_module+0x81/0x2c0<br /> [77346.173491] load_module+0x1232/0x12c0<br /> [77346.173506] __do_sys_finit_module+0x101/0x180<br /> [77346.173522] __x64_sys_finit_module+0x3c/0x50<br /> [77346.173538] do_syscall_64+0x39/0x90<br /> [77346.173553] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [77346.173634] value changed: 0x0000000000000094 -&gt; 0x0000000000000095

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Disable preemption in bpf_perf_event_output<br /> <br /> The nesting protection in bpf_perf_event_output relies on disabled<br /> preemption, which is guaranteed for kprobes and tracepoints.<br /> <br /> However bpf_perf_event_output can be also called from uprobes context<br /> through bpf_prog_run_array_sleepable function which disables migration,<br /> but keeps preemption enabled.<br /> <br /> This can cause task to be preempted by another one inside the nesting<br /> protection and lead eventually to two tasks using same perf_sample_data<br /> buffer and cause crashes like:<br /> <br /> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)<br /> BUG: unable to handle page fault for address: ffffffff82be3eea<br /> ...<br /> Call Trace:<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x176/0x4d0<br /> ? exc_page_fault+0x132/0x230<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? perf_output_sample+0x12b/0x910<br /> ? perf_event_output+0xd0/0x1d0<br /> ? bpf_perf_event_output+0x162/0x1d0<br /> ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87<br /> ? __uprobe_perf_func+0x12b/0x540<br /> ? uprobe_dispatcher+0x2c4/0x430<br /> ? uprobe_notify_resume+0x2da/0xce0<br /> ? atomic_notifier_call_chain+0x7b/0x110<br /> ? exit_to_user_mode_prepare+0x13e/0x290<br /> ? irqentry_exit_to_user_mode+0x5/0x30<br /> ? asm_exc_int3+0x35/0x40<br /> <br /> Fixing this by disabling preemption in bpf_perf_event_output.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: meson_sm: fix to avoid potential NULL pointer dereference<br /> <br /> of_match_device() may fail and returns a NULL pointer.<br /> <br /> Fix this by checking the return value of of_match_device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: refuse to create ea block when umounted<br /> <br /> The ea block expansion need to access s_root while it is<br /> already set as NULL when umount is triggered. Refuse this<br /> request to avoid panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: avoid hanging tasks on the tx_lock<br /> <br /> syzbot sent a hung task report and Eric explains that adversarial<br /> receiver may keep RWIN at 0 for a long time, so we are not guaranteed<br /> to make forward progress. Thread which took tx_lock and went to sleep<br /> may not release tx_lock for hours. Use interruptible sleep where<br /> possible and reschedule the work if it can&amp;#39;t take the lock.<br /> <br /> Testing: existing selftest passes

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp_qoriq: fix memory leak in probe()<br /> <br /> Smatch complains that:<br /> drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()<br /> warn: &amp;#39;base&amp;#39; from ioremap() not released.<br /> <br /> Fix this by revising the parameter from &amp;#39;ptp_qoriq-&gt;base&amp;#39; to &amp;#39;base&amp;#39;.<br /> This is only a bug if ptp_qoriq_init() returns on the<br /> first -ENODEV error path.<br /> For other error paths ptp_qoriq-&gt;base and base are the same.<br /> And this change makes the code more readable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ymfpci: Create card with device-managed snd_devm_card_new()<br /> <br /> snd_card_ymfpci_remove() was removed in commit c6e6bb5eab74 ("ALSA:<br /> ymfpci: Allocate resources with device-managed APIs"), but the call to<br /> snd_card_new() was not replaced with snd_devm_card_new().<br /> <br /> Since there was no longer a call to snd_card_free, unloading the module<br /> would eventually result in Oops:<br /> <br /> [697561.532887] BUG: unable to handle page fault for address: ffffffffc0924480<br /> [697561.532893] #PF: supervisor read access in kernel mode<br /> [697561.532896] #PF: error_code(0x0000) - not-present page<br /> [697561.532899] PGD ae1e15067 P4D ae1e15067 PUD ae1e17067 PMD 11a8f5067 PTE 0<br /> [697561.532905] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [697561.532909] CPU: 21 PID: 5080 Comm: wireplumber Tainted: G W OE 6.2.7 #1<br /> [697561.532914] Hardware name: System manufacturer System Product Name/TUF GAMING X570-PLUS, BIOS 4408 10/28/2022<br /> [697561.532916] RIP: 0010:try_module_get.part.0+0x1a/0xe0<br /> [697561.532924] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc bf 01 00 00 00 e8 56 3c f8 ff 83 3c 24 02 0f 84 96 00 00 00 41 8b 84 24 30 03 00 00 85 c0 0f<br /> [697561.532927] RSP: 0018:ffffbe9b858c3bd8 EFLAGS: 00010246<br /> [697561.532930] RAX: ffff9815d14f1900 RBX: ffff9815c14e6000 RCX: 0000000000000000<br /> [697561.532933] RDX: 0000000000000000 RSI: ffffffffc055092c RDI: ffffffffb3778c1a<br /> [697561.532935] RBP: ffffbe9b858c3be8 R08: 0000000000000040 R09: ffff981a1a741380<br /> [697561.532937] R10: ffffbe9b858c3c80 R11: 00000009d56533a6 R12: ffffffffc0924480<br /> [697561.532939] R13: ffff9823439d8500 R14: 0000000000000025 R15: ffff9815cd109f80<br /> [697561.532942] FS: 00007f13084f1f80(0000) GS:ffff9824aef40000(0000) knlGS:0000000000000000<br /> [697561.532945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [697561.532947] CR2: ffffffffc0924480 CR3: 0000000145344000 CR4: 0000000000350ee0<br /> [697561.532949] Call Trace:<br /> [697561.532951] <br /> [697561.532955] try_module_get+0x13/0x30<br /> [697561.532960] snd_ctl_open+0x61/0x1c0 [snd]<br /> [697561.532976] snd_open+0xb4/0x1e0 [snd]<br /> [697561.532989] chrdev_open+0xc7/0x240<br /> [697561.532995] ? fsnotify_perm.part.0+0x6e/0x160<br /> [697561.533000] ? __pfx_chrdev_open+0x10/0x10<br /> [697561.533005] do_dentry_open+0x169/0x440<br /> [697561.533009] vfs_open+0x2d/0x40<br /> [697561.533012] path_openat+0xa9d/0x10d0<br /> [697561.533017] ? debug_smp_processor_id+0x17/0x20<br /> [697561.533022] ? trigger_load_balance+0x65/0x370<br /> [697561.533026] do_filp_open+0xb2/0x160<br /> [697561.533032] ? _raw_spin_unlock+0x19/0x40<br /> [697561.533036] ? alloc_fd+0xa9/0x190<br /> [697561.533040] do_sys_openat2+0x9f/0x160<br /> [697561.533044] __x64_sys_openat+0x55/0x90<br /> [697561.533048] do_syscall_64+0x3b/0x90<br /> [697561.533052] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [697561.533056] RIP: 0033:0x7f1308a40db4<br /> [697561.533059] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 46 68 f8 ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 78 68 f8 ff 8b 44<br /> [697561.533062] RSP: 002b:00007ffcce664450 EFLAGS: 00000293 ORIG_RAX: 0000000000000101<br /> [697561.533066] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1308a40db4<br /> [697561.533068] RDX: 0000000000080000 RSI: 00007ffcce664690 RDI: 00000000ffffff9c<br /> [697561.533070] RBP: 00007ffcce664690 R08: 0000000000000000 R09: 0000000000000012<br /> [697561.533072] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000080000<br /> [697561.533074] R13: 00007f13054b069b R14: 0000565209f83200 R15: 0000000000000000<br /> [697561.533078]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: fix NULL pointer dereference<br /> <br /> vduse_vdpa_set_vq_affinity callback can be called<br /> with NULL value as cpu_mask when deleting the vduse<br /> device.<br /> <br /> This patch resets virtqueue&amp;#39;s IRQ affinity mask value<br /> to set all CPUs instead of dereferencing NULL cpu_mask.<br /> <br /> [ 4760.952149] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 4760.959110] #PF: supervisor read access in kernel mode<br /> [ 4760.964247] #PF: error_code(0x0000) - not-present page<br /> [ 4760.969385] PGD 0 P4D 0<br /> [ 4760.971927] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 4760.976112] CPU: 13 PID: 2346 Comm: vdpa Not tainted 6.4.0-rc6+ #4<br /> [ 4760.982291] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.8.1 06/26/2020<br /> [ 4760.989769] RIP: 0010:memcpy_orig+0xc5/0x130<br /> [ 4760.994049] Code: 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 fa 08 72 1b 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 cc cc cc cc 66<br /> [ 4761.012793] RSP: 0018:ffffb1d565abb830 EFLAGS: 00010246<br /> [ 4761.018020] RAX: ffff9f4bf6b27898 RBX: ffff9f4be23969c0 RCX: ffff9f4bcadf6400<br /> [ 4761.025152] RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff9f4bf6b27898<br /> [ 4761.032286] RBP: 0000000000000000 R08: 0000000000000008 R09: 0000000000000000<br /> [ 4761.039416] R10: 0000000000000000 R11: 0000000000000600 R12: 0000000000000000<br /> [ 4761.046549] R13: 0000000000000000 R14: 0000000000000080 R15: ffffb1d565abbb10<br /> [ 4761.053680] FS: 00007f64c2ec2740(0000) GS:ffff9f635f980000(0000) knlGS:0000000000000000<br /> [ 4761.061765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4761.067513] CR2: 0000000000000000 CR3: 0000001875270006 CR4: 00000000007706e0<br /> [ 4761.074645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4761.081775] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 4761.088909] PKRU: 55555554<br /> [ 4761.091620] Call Trace:<br /> [ 4761.094074] <br /> [ 4761.096180] ? __die+0x1f/0x70<br /> [ 4761.099238] ? page_fault_oops+0x171/0x4f0<br /> [ 4761.103340] ? exc_page_fault+0x7b/0x180<br /> [ 4761.107265] ? asm_exc_page_fault+0x22/0x30<br /> [ 4761.111460] ? memcpy_orig+0xc5/0x130<br /> [ 4761.115126] vduse_vdpa_set_vq_affinity+0x3e/0x50 [vduse]<br /> [ 4761.120533] virtnet_clean_affinity.part.0+0x3d/0x90 [virtio_net]<br /> [ 4761.126635] remove_vq_common+0x1a4/0x250 [virtio_net]<br /> [ 4761.131781] virtnet_remove+0x5d/0x70 [virtio_net]<br /> [ 4761.136580] virtio_dev_remove+0x3a/0x90<br /> [ 4761.140509] device_release_driver_internal+0x19b/0x200<br /> [ 4761.145742] bus_remove_device+0xc2/0x130<br /> [ 4761.149755] device_del+0x158/0x3e0<br /> [ 4761.153245] ? kernfs_find_ns+0x35/0xc0<br /> [ 4761.157086] device_unregister+0x13/0x60<br /> [ 4761.161010] unregister_virtio_device+0x11/0x20<br /> [ 4761.165543] device_release_driver_internal+0x19b/0x200<br /> [ 4761.170770] bus_remove_device+0xc2/0x130<br /> [ 4761.174782] device_del+0x158/0x3e0<br /> [ 4761.178276] ? __pfx_vdpa_name_match+0x10/0x10 [vdpa]<br /> [ 4761.183336] device_unregister+0x13/0x60<br /> [ 4761.187260] vdpa_nl_cmd_dev_del_set_doit+0x63/0xe0 [vdpa]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix data race on CQP request done<br /> <br /> KCSAN detects a data race on cqp_request-&gt;request_done memory location<br /> which is accessed locklessly in irdma_handle_cqp_op while being<br /> updated in irdma_cqp_ce_handler.<br /> <br /> Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid any<br /> compiler optimizations like load fusing and/or KCSAN warning.<br /> <br /> [222808.417128] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma]<br /> <br /> [222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:<br /> [222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma]<br /> [222808.417725] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [222808.417827] process_one_work+0x4d1/0xa40<br /> [222808.417835] worker_thread+0x319/0x700<br /> [222808.417842] kthread+0x180/0x1b0<br /> [222808.417852] ret_from_fork+0x22/0x30<br /> <br /> [222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:<br /> [222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma]<br /> [222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma]<br /> [222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma]<br /> [222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma]<br /> [222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma]<br /> [222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma]<br /> [222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core]<br /> [222808.418823] __ib_unregister_device+0xde/0x100 [ib_core]<br /> [222808.418981] ib_unregister_device+0x22/0x40 [ib_core]<br /> [222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma]<br /> [222808.419248] i40iw_close+0x6f/0xc0 [irdma]<br /> [222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e]<br /> [222808.419450] i40iw_remove+0x21/0x30 [irdma]<br /> [222808.419554] auxiliary_bus_remove+0x31/0x50<br /> [222808.419563] device_remove+0x69/0xb0<br /> [222808.419572] device_release_driver_internal+0x293/0x360<br /> [222808.419582] driver_detach+0x7c/0xf0<br /> [222808.419592] bus_remove_driver+0x8c/0x150<br /> [222808.419600] driver_unregister+0x45/0x70<br /> [222808.419610] auxiliary_driver_unregister+0x16/0x30<br /> [222808.419618] irdma_exit_module+0x18/0x1e [irdma]<br /> [222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310<br /> [222808.419745] __x64_sys_delete_module+0x1b/0x30<br /> [222808.419755] do_syscall_64+0x39/0x90<br /> [222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [222808.419829] value changed: 0x01 -&gt; 0x03