Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()<br /> <br /> It is possible that skb is freed in ath9k_htc_rx_msg(), then<br /> usb_submit_urb() fails and we try to free skb again. It causes<br /> use-after-free bug. Moreover, if alloc_skb() fails, urb-&gt;context becomes<br /> NULL but rx_buf is not freed and there can be a memory leak.<br /> <br /> The patch removes unnecessary nskb and makes skb processing more clear: it<br /> is supposed that ath9k_htc_rx_msg() either frees old skb or passes its<br /> managing to another callback function.<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 /> auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()<br /> <br /> hd44780_probe() allocates a memory chunk for hd with kzalloc() and<br /> makes "lcd-&gt;drvdata-&gt;hd44780" point to it. When we call hd44780_remove(),<br /> we should release all relevant memory and resource. But "lcd-&gt;drvdata<br /> -&gt;hd44780" is not released, which will lead to a memory leak.<br /> <br /> We should release the "lcd-&gt;drvdata-&gt;hd44780" in hd44780_remove() to fix<br /> the memory leak bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()<br /> <br /> The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, add<br /> dev_kfree_skb() to fix it. Compile tested only.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: use hdev-&gt;workqueue when queuing hdev-&gt;{cmd,ncmd}_timer works<br /> <br /> syzbot is reporting attempt to schedule hdev-&gt;cmd_work work from system_wq<br /> WQ into hdev-&gt;workqueue WQ which is under draining operation [1], for<br /> commit c8efcc2589464ac7 ("workqueue: allow chained queueing during<br /> destruction") does not allow such operation.<br /> <br /> The check introduced by commit 877afadad2dce8aa ("Bluetooth: When HCI work<br /> queue is drained, only queue chained work") was incomplete.<br /> <br /> Use hdev-&gt;workqueue WQ when queuing hdev-&gt;{cmd,ncmd}_timer works because<br /> hci_{cmd,ncmd}_timeout() calls queue_work(hdev-&gt;workqueue). Also, protect<br /> the queuing operation with RCU read lock in order to avoid calling<br /> queue_delayed_work() after cancel_delayed_work() completed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: Fix potential resource leaks<br /> <br /> nfc_get_device() take reference for the device, add missing<br /> nfc_put_device() to release it when not need anymore.<br /> Also fix the style warnning by use error EOPNOTSUPP instead of<br /> ENOTSUPP.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: avoid possible NULL deref in skb_clone()<br /> <br /> syzbot got a crash [1] in skb_clone(), caused by a bug<br /> in hsr_get_untagged_frame().<br /> <br /> When/if create_stripped_skb_hsr() returns NULL, we must<br /> not attempt to call skb_clone().<br /> <br /> While we are at it, replace a WARN_ONCE() by netdev_warn_once().<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641<br /> Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00<br /> RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207<br /> <br /> RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000<br /> RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140<br /> R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640<br /> R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620<br /> FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164<br /> hsr_forward_do net/hsr/hsr_forward.c:461 [inline]<br /> hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623<br /> hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69<br /> __netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379<br /> __netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483<br /> __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599<br /> netif_receive_skb_internal net/core/dev.c:5685 [inline]<br /> netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744<br /> tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544<br /> tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995<br /> tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025<br /> call_write_iter include/linux/fs.h:2187 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x9e9/0xdd0 fs/read_write.c:584<br /> ksys_write+0x127/0x250 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix running_req for internal abort commands<br /> <br /> Disabling the remote phy for a SATA disk causes a hang:<br /> <br /> root@(none)$ more /sys/class/sas_phy/phy-0:0:8/target_port_protocols<br /> sata<br /> root@(none)$ echo 0 &gt; sys/class/sas_phy/phy-0:0:8/enable<br /> root@(none)$ [ 67.855950] sas: ex 500e004aaaaaaa1f phy08 change count has changed<br /> [ 67.920585] sd 0:0:2:0: [sdc] Synchronizing SCSI cache<br /> [ 67.925780] sd 0:0:2:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK<br /> [ 67.935094] sd 0:0:2:0: [sdc] Stopping disk<br /> [ 67.939305] sd 0:0:2:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK<br /> ...<br /> [ 123.998998] INFO: task kworker/u192:1:642 blocked for more than 30 seconds.<br /> [ 124.005960] Not tainted 6.0.0-rc1-205202-gf26f8f761e83 #218<br /> [ 124.012049] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 124.019872] task:kworker/u192:1 state:D stack:0 pid: 642 ppid: 2 flags:0x00000008<br /> [ 124.028223] Workqueue: 0000:04:00.0_event_q sas_port_event_worker<br /> [ 124.034319] Call trace:<br /> [ 124.036758] __switch_to+0x128/0x278<br /> [ 124.040333] __schedule+0x434/0xa58<br /> [ 124.043820] schedule+0x94/0x138<br /> [ 124.047045] schedule_timeout+0x2fc/0x368<br /> [ 124.051052] wait_for_completion+0xdc/0x200<br /> [ 124.055234] __flush_workqueue+0x1a8/0x708<br /> [ 124.059328] sas_porte_broadcast_rcvd+0xa8/0xc0<br /> [ 124.063858] sas_port_event_worker+0x60/0x98<br /> [ 124.068126] process_one_work+0x3f8/0x660<br /> [ 124.072134] worker_thread+0x70/0x700<br /> [ 124.075793] kthread+0x1a4/0x1b8<br /> [ 124.079014] ret_from_fork+0x10/0x20<br /> <br /> The issue is that the per-device running_req read in<br /> pm8001_dev_gone_notify() never goes to zero and we never make progress.<br /> This is caused by missing accounting for running_req for when an internal<br /> abort command completes.<br /> <br /> In commit 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support")<br /> we started to send internal abort commands as a proper sas_task. In this<br /> when we deliver a sas_task to HW the per-device running_req is incremented<br /> in pm8001_queue_command(). However it is never decremented for internal<br /> abort commnds, so decrement in pm8001_mpi_task_abort_resp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: Set ubuf-&gt;sg = NULL if the creation of sg table fails<br /> <br /> When userspace tries to map the dmabuf and if for some reason<br /> (e.g. OOM) the creation of the sg table fails, ubuf-&gt;sg needs to be<br /> set to NULL. Otherwise, when the userspace subsequently closes the<br /> dmabuf fd, we&amp;#39;d try to erroneously free the invalid sg table from<br /> release_udmabuf resulting in the following crash reported by syzbot:<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 3609 Comm: syz-executor487 Not tainted<br /> 5.19.0-syzkaller-13930-g7ebfc85e2cd7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 07/22/2022<br /> RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]<br /> RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]<br /> RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114<br /> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c<br /> 8b 63 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 14<br /> 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2<br /> RSP: 0018:ffffc900037efd30 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffffffff8cb67800 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff84ad27e0 RDI: 0000000000000000<br /> RBP: fffffffffffffff4 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 000000000008c07c R12: ffff88801fa05000<br /> R13: ffff888073db07e8 R14: ffff888025c25440 R15: 0000000000000000<br /> FS: 0000555555fc4300(0000) GS:ffff8880b9a00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc1c0ce06e4 CR3: 00000000715e6000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dma_buf_release+0x157/0x2d0 drivers/dma-buf/dma-buf.c:78<br /> __dentry_kill+0x42b/0x640 fs/dcache.c:612<br /> dentry_kill fs/dcache.c:733 [inline]<br /> dput+0x806/0xdb0 fs/dcache.c:913<br /> __fput+0x39c/0x9d0 fs/file_table.c:333<br /> task_work_run+0xdd/0x1a0 kernel/task_work.c:177<br /> ptrace_notify+0x114/0x140 kernel/signal.c:2353<br /> ptrace_report_syscall include/linux/ptrace.h:420 [inline]<br /> ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]<br /> syscall_exit_work kernel/entry/common.c:249 [inline]<br /> syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]<br /> syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294<br /> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fc1c0c35b6b<br /> Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24<br /> 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44<br /> RSP: 002b:00007ffd78a06090 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1c0c35b6b<br /> RDX: 0000000020000280 RSI: 0000000040086200 RDI: 0000000000000006<br /> RBP: 0000000000000007 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000000c<br /> R13: 0000000000000003 R14: 00007fc1c0cfe4a0 R15: 00007ffd78a06140<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]<br /> RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]<br /> RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()<br /> <br /> dmc620_pmu_init() won&amp;#39;t remove the callback added by<br /> cpuhp_setup_state_multi() when platform_driver_register() failed. Remove<br /> the callback by cpuhp_remove_multi_state() in fail path.<br /> <br /> Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:<br /> arm-ccn: Prevent hotplug callback leak")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Don&amp;#39;t leak netobj memory when gss_read_proxy_verf() fails

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/restrack: Release MR restrack when delete<br /> <br /> The MR restrack also needs to be released when delete it, otherwise it<br /> cause memory leak as the task struct won&amp;#39;t be released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: tegra: Fix refcount leak in tegra114_clock_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.