Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix resource leak in ksmbd_session_rpc_open()<br /> <br /> When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to<br /> undo the result of ksmbd_ipc_id_alloc().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: silence the warning when evicting inode with dioread_nolock<br /> <br /> When evicting an inode with default dioread_nolock, it could be raced by<br /> the unwritten extents converting kworker after writeback some new<br /> allocated dirty blocks. It convert unwritten extents to written, the<br /> extents could be merged to upper level and free extent blocks, so it<br /> could mark the inode dirty again even this inode has been marked<br /> I_FREEING. But the inode-&gt;i_io_list check and warning in<br /> ext4_evict_inode() missing this corner case. Fortunately,<br /> ext4_evict_inode() will wait all extents converting finished before this<br /> check, so it will not lead to inode use-after-free problem, every thing<br /> is OK besides this warning. The WARN_ON_ONCE was originally designed<br /> for finding inode use-after-free issues in advance, but if we add<br /> current dioread_nolock case in, it will become not quite useful, so fix<br /> this warning by just remove this check.<br /> <br /> ======<br /> WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227<br /> ext4_evict_inode+0x875/0xc60<br /> ...<br /> RIP: 0010:ext4_evict_inode+0x875/0xc60<br /> ...<br /> Call Trace:<br /> <br /> evict+0x11c/0x2b0<br /> iput+0x236/0x3a0<br /> do_unlinkat+0x1b4/0x490<br /> __x64_sys_unlinkat+0x4c/0xb0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fa933c1115b<br /> ======<br /> <br /> rm kworker<br /> ext4_end_io_end()<br /> vfs_unlink()<br /> ext4_unlink()<br /> ext4_convert_unwritten_io_end_vec()<br /> ext4_convert_unwritten_extents()<br /> ext4_map_blocks()<br /> ext4_ext_map_blocks()<br /> ext4_ext_try_to_merge_up()<br /> __mark_inode_dirty()<br /> check !I_FREEING<br /> locked_inode_to_wb_and_lock_list()<br /> iput()<br /> iput_final()<br /> evict()<br /> ext4_evict_inode()<br /> truncate_inode_pages_final() //wait release io_end<br /> inode_io_list_move_locked()<br /> ext4_release_io_end()<br /> trigger WARN_ON_ONCE()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: akcipher - default implementation for setting a private key<br /> <br /> Changes from v1:<br /> * removed the default implementation from set_pub_key: it is assumed that<br /> an implementation must always have this callback defined as there are<br /> no use case for an algorithm, which doesn&amp;#39;t need a public key<br /> <br /> Many akcipher implementations (like ECDSA) support only signature<br /> verifications, so they don&amp;#39;t have all callbacks defined.<br /> <br /> Commit 78a0324f4a53 ("crypto: akcipher - default implementations for<br /> request callbacks") introduced default callbacks for sign/verify<br /> operations, which just return an error code.<br /> <br /> However, these are not enough, because before calling sign the caller would<br /> likely call set_priv_key first on the instantiated transform (as the<br /> in-kernel testmgr does). This function does not have a default stub, so the<br /> kernel crashes, when trying to set a private key on an akcipher, which<br /> doesn&amp;#39;t support signature generation.<br /> <br /> I&amp;#39;ve noticed this, when trying to add a KAT vector for ECDSA signature to<br /> the testmgr.<br /> <br /> With this patch the testmgr returns an error in dmesg (as it should)<br /> instead of crashing the kernel NULL ptr dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8192u: Fix use after free in ieee80211_rx()<br /> <br /> We cannot dereference the "skb" pointer after calling<br /> ieee80211_monitor_rx(), because it is a use after free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: idmouse: fix an uninit-value in idmouse_open<br /> <br /> In idmouse_create_image, if any ftip_command fails, it will<br /> go to the reset label. However, this leads to the data in<br /> bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check<br /> for valid image incurs an uninitialized dereference.<br /> <br /> Fix this by moving the check before reset label since this<br /> check only be valid if the data after bulk_in_buffer[HEADER]<br /> has concrete data.<br /> <br /> Note that this is found by KMSAN, so only kernel compilation<br /> is tested.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921e: fix rmmod crash in driver reload test<br /> <br /> In insmod/rmmod stress test, the following crash dump shows up immediately.<br /> The problem is caused by missing mt76_dev in mt7921_pci_remove(). We<br /> should make sure the drvdata is ready before probe() finished.<br /> <br /> [168.862789] ==================================================================<br /> [168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480<br /> [168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361<br /> [168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G OE 5.19.0-rc6 #1<br /> [168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020<br /> [168.862820] Call Trace:<br /> [168.862822] <br /> [168.862825] dump_stack_lvl+0x49/0x63<br /> [168.862832] print_report.cold+0x493/0x6b7<br /> [168.862845] kasan_report+0xa7/0x120<br /> [168.862857] kasan_check_range+0x163/0x200<br /> [168.862861] __kasan_check_write+0x14/0x20<br /> [168.862866] try_to_grab_pending+0x59/0x480<br /> [168.862870] __cancel_work_timer+0xbb/0x340<br /> [168.862898] cancel_work_sync+0x10/0x20<br /> [168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e]<br /> [168.862909] pci_device_remove+0xa3/0x1d0<br /> [168.862914] device_remove+0xc4/0x170<br /> [168.862920] device_release_driver_internal+0x163/0x300<br /> [168.862925] driver_detach+0xc7/0x1a0<br /> [168.862930] bus_remove_driver+0xeb/0x2d0<br /> [168.862935] driver_unregister+0x71/0xb0<br /> [168.862939] pci_unregister_driver+0x30/0x230<br /> [168.862944] mt7921_pci_driver_exit+0x10/0x1b [mt7921e]<br /> [168.862949] __x64_sys_delete_module+0x2f9/0x4b0<br /> [168.862968] do_syscall_64+0x38/0x90<br /> [168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Test steps:<br /> 1. insmode<br /> 2. do not ifup<br /> 3. rmmod quickly (within 1 second)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1: stop mdx_raid1 thread when raid1 array run failed<br /> <br /> fail run raid1 array when we assemble array with the inactive disk only,<br /> but the mdx_raid1 thread were not stop, Even if the associated resources<br /> have been released. it will caused a NULL dereference when we do poweroff.<br /> <br /> This causes the following Oops:<br /> [ 287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070<br /> [ 287.594762] #PF: supervisor read access in kernel mode<br /> [ 287.599912] #PF: error_code(0x0000) - not-present page<br /> [ 287.605061] PGD 0 P4D 0<br /> [ 287.607612] Oops: 0000 [#1] SMP NOPTI<br /> [ 287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G U 5.10.146 #0<br /> [ 287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022<br /> [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod]<br /> [ 287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ......<br /> [ 287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202<br /> [ 287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000<br /> [ 287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800<br /> [ 287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff<br /> [ 287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800<br /> [ 287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500<br /> [ 287.692052] FS: 0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000<br /> [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0<br /> [ 287.713033] Call Trace:<br /> [ 287.715498] raid1d+0x6c/0xbbb [raid1]<br /> [ 287.719256] ? __schedule+0x1ff/0x760<br /> [ 287.722930] ? schedule+0x3b/0xb0<br /> [ 287.726260] ? schedule_timeout+0x1ed/0x290<br /> [ 287.730456] ? __switch_to+0x11f/0x400<br /> [ 287.734219] md_thread+0xe9/0x140 [md_mod]<br /> [ 287.738328] ? md_thread+0xe9/0x140 [md_mod]<br /> [ 287.742601] ? wait_woken+0x80/0x80<br /> [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod]<br /> [ 287.751064] kthread+0x11a/0x140<br /> [ 287.754300] ? kthread_park+0x90/0x90<br /> [ 287.757974] ret_from_fork+0x1f/0x30<br /> <br /> In fact, when raid1 array run fail, we need to do<br /> md_unregister_thread() before raid1_free().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ar5523: Fix use-after-free on ar5523_cmd() timed out<br /> <br /> syzkaller reported use-after-free with the stack trace like below [1]:<br /> <br /> [ 38.960489][ C3] ==================================================================<br /> [ 38.963216][ C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240<br /> [ 38.964950][ C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0<br /> [ 38.966363][ C3]<br /> [ 38.967053][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18<br /> [ 38.968464][ C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014<br /> [ 38.969959][ C3] Call Trace:<br /> [ 38.970841][ C3] <br /> [ 38.971663][ C3] dump_stack_lvl+0xfc/0x174<br /> [ 38.972620][ C3] print_report.cold+0x2c3/0x752<br /> [ 38.973626][ C3] ? ar5523_cmd_tx_cb+0x220/0x240<br /> [ 38.974644][ C3] kasan_report+0xb1/0x1d0<br /> [ 38.975720][ C3] ? ar5523_cmd_tx_cb+0x220/0x240<br /> [ 38.976831][ C3] ar5523_cmd_tx_cb+0x220/0x240<br /> [ 38.978412][ C3] __usb_hcd_giveback_urb+0x353/0x5b0<br /> [ 38.979755][ C3] usb_hcd_giveback_urb+0x385/0x430<br /> [ 38.981266][ C3] dummy_timer+0x140c/0x34e0<br /> [ 38.982925][ C3] ? notifier_call_chain+0xb5/0x1e0<br /> [ 38.984761][ C3] ? rcu_read_lock_sched_held+0xb/0x60<br /> [ 38.986242][ C3] ? lock_release+0x51c/0x790<br /> [ 38.987323][ C3] ? _raw_read_unlock_irqrestore+0x37/0x70<br /> [ 38.988483][ C3] ? __wake_up_common_lock+0xde/0x130<br /> [ 38.989621][ C3] ? reacquire_held_locks+0x4a0/0x4a0<br /> [ 38.990777][ C3] ? lock_acquire+0x472/0x550<br /> [ 38.991919][ C3] ? rcu_read_lock_sched_held+0xb/0x60<br /> [ 38.993138][ C3] ? lock_acquire+0x472/0x550<br /> [ 38.994890][ C3] ? dummy_urb_enqueue+0x860/0x860<br /> [ 38.996266][ C3] ? do_raw_spin_unlock+0x16f/0x230<br /> [ 38.997670][ C3] ? dummy_urb_enqueue+0x860/0x860<br /> [ 38.999116][ C3] call_timer_fn+0x1a0/0x6a0<br /> [ 39.000668][ C3] ? add_timer_on+0x4a0/0x4a0<br /> [ 39.002137][ C3] ? reacquire_held_locks+0x4a0/0x4a0<br /> [ 39.003809][ C3] ? __next_timer_interrupt+0x226/0x2a0<br /> [ 39.005509][ C3] __run_timers.part.0+0x69a/0xac0<br /> [ 39.007025][ C3] ? dummy_urb_enqueue+0x860/0x860<br /> [ 39.008716][ C3] ? call_timer_fn+0x6a0/0x6a0<br /> [ 39.010254][ C3] ? cpuacct_percpu_seq_show+0x10/0x10<br /> [ 39.011795][ C3] ? kvm_sched_clock_read+0x14/0x40<br /> [ 39.013277][ C3] ? sched_clock_cpu+0x69/0x2b0<br /> [ 39.014724][ C3] run_timer_softirq+0xb6/0x1d0<br /> [ 39.016196][ C3] __do_softirq+0x1d2/0x9be<br /> [ 39.017616][ C3] __irq_exit_rcu+0xeb/0x190<br /> [ 39.019004][ C3] irq_exit_rcu+0x5/0x20<br /> [ 39.020361][ C3] sysvec_apic_timer_interrupt+0x8f/0xb0<br /> [ 39.021965][ C3] <br /> [ 39.023237][ C3] <br /> <br /> In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below<br /> (there are other functions which finally call ar5523_cmd()):<br /> <br /> ar5523_probe()<br /> -&gt; ar5523_host_available()<br /> -&gt; ar5523_cmd_read()<br /> -&gt; ar5523_cmd()<br /> <br /> If ar5523_cmd() timed out, then ar5523_host_available() failed and<br /> ar5523_probe() freed the device structure. So, ar5523_cmd_tx_cb()<br /> might touch the freed structure.<br /> <br /> This patch fixes this issue by canceling in-flight tx cmd if submitted<br /> urb timed out.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: add bounds check on Transfer Tag<br /> <br /> ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(),<br /> add a bounds check to avoid out-of-bounds access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix pci device refcount leak<br /> <br /> As comment of pci_get_domain_bus_and_slot() says, it returns<br /> a pci device with refcount increment, when finish using it,<br /> the caller must decrement the reference count by calling<br /> pci_dev_put().<br /> <br /> So before returning from amdgpu_device_resume|suspend_display_audio(),<br /> pci_dev_put() is called to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: line6: fix stack overflow in line6_midi_transmit<br /> <br /> Correctly calculate available space including the size of the chunk<br /> buffer. This fixes a buffer overflow when multiple MIDI sysex<br /> messages are sent to a PODxt device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/apic: Don&amp;#39;t disable x2APIC if locked<br /> <br /> The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC<br /> (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but<br /> it disables the memory-mapped APIC interface in favor of one that uses<br /> MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.<br /> <br /> The MMIO/xAPIC interface has some problems, most notably the APIC LEAK<br /> [1]. This bug allows an attacker to use the APIC MMIO interface to<br /> extract data from the SGX enclave.<br /> <br /> Introduce support for a new feature that will allow the BIOS to lock<br /> the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the<br /> kernel tries to disable the APIC or revert to legacy APIC mode a GP<br /> fault will occur.<br /> <br /> Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle<br /> the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by<br /> preventing the kernel from trying to disable the x2APIC.<br /> <br /> On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are<br /> enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. If<br /> legacy APIC is required, then it SGX and TDX need to be disabled in the<br /> BIOS.<br /> <br /> [1]: https://aepicleak.com/aepicleak.pdf