Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix null-ptr-deref in raid10_sync_request<br /> <br /> init_resync() inits mempool and sets conf-&gt;have_replacemnt at the beginning<br /> of sync, close_sync() frees the mempool when sync is completed.<br /> <br /> After [1] recovery might be skipped and init_resync() is called but<br /> close_sync() is not. null-ptr-deref occurs with r10bio-&gt;dev[i].repl_bio.<br /> <br /> The following is one way to reproduce the issue.<br /> <br /> 1) create a array, wait for resync to complete, mddev-&gt;recovery_cp is set<br /> to MaxSector.<br /> 2) recovery is woken and it is skipped. conf-&gt;have_replacement is set to<br /> 0 in init_resync(). close_sync() not called.<br /> 3) some io errors and rdev A is set to WantReplacement.<br /> 4) a new device is added and set to A&amp;#39;s replacement.<br /> 5) recovery is woken, A have replacement, but conf-&gt;have_replacemnt is<br /> 0. r10bio-&gt;dev[i].repl_bio will not be alloced and null-ptr-deref<br /> occurs.<br /> <br /> Fix it by not calling init_resync() if recovery skipped.<br /> <br /> [1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix NULL ptr deref by checking new_crtc_state<br /> <br /> intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn&amp;#39;t<br /> obtained previously with intel_atomic_get_crtc_state, so we must check it<br /> for NULLness here, just as in many other places, where we can&amp;#39;t guarantee<br /> that intel_atomic_get_crtc_state was called.<br /> We are currently getting NULL ptr deref because of that, so this fix was<br /> confirmed to help.<br /> <br /> (cherry picked from commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ina2xx: avoid NULL pointer dereference on OF device match<br /> <br /> The affected lines were resulting in a NULL pointer dereference on our<br /> platform because the device tree contained the following list of<br /> compatible strings:<br /> <br /> power-sensor@40 {<br /> compatible = "ti,ina232", "ti,ina231";<br /> ...<br /> };<br /> <br /> Since the driver doesn&amp;#39;t declare a compatible string "ti,ina232", the OF<br /> matching succeeds on "ti,ina231". But the I2C device ID info is<br /> populated via the first compatible string, cf. modalias population in<br /> of_i2c_get_board_info(). Since there is no "ina232" entry in the legacy<br /> I2C device ID table either, the struct i2c_device_id *id pointer in the<br /> probe function is NULL.<br /> <br /> Fix this by using the already populated type variable instead, which<br /> points to the proper driver data. Since the name is also wanted, add a<br /> generic one to the ina2xx_config table.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix skb refcnt race after locking changes<br /> <br /> There is a race where skb&amp;#39;s from the sk_psock_backlog can be referenced<br /> after userspace side has already skb_consumed() the sk_buff and its refcnt<br /> dropped to zer0 causing use after free.<br /> <br /> The flow is the following:<br /> <br /> while ((skb = skb_peek(&amp;psock-&gt;ingress_skb))<br /> sk_psock_handle_Skb(psock, skb, ..., ingress)<br /> if (!ingress) ...<br /> sk_psock_skb_ingress<br /> sk_psock_skb_ingress_enqueue(skb)<br /> msg-&gt;skb = skb<br /> sk_psock_queue_msg(psock, msg)<br /> skb_dequeue(&amp;psock-&gt;ingress_skb)<br /> <br /> The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is<br /> what the application reads when recvmsg() is called. An application can<br /> read this anytime after the msg is placed on the queue. The recvmsg hook<br /> will also read msg-&gt;skb and then after user space reads the msg will call<br /> consume_skb(skb) on it effectively free&amp;#39;ing it.<br /> <br /> But, the race is in above where backlog queue still has a reference to<br /> the skb and calls skb_dequeue(). If the skb_dequeue happens after the<br /> user reads and free&amp;#39;s the skb we have a use after free.<br /> <br /> The !ingress case does not suffer from this problem because it uses<br /> sendmsg_*(sk, msg) which does not pass the sk_buff further down the<br /> stack.<br /> <br /> The following splat was observed with &amp;#39;test_progs -t sockmap_listen&amp;#39;:<br /> <br /> [ 1022.710250][ T2556] general protection fault, ...<br /> [...]<br /> [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog<br /> [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80<br /> [ 1022.713653][ T2556] Code: ...<br /> [...]<br /> [ 1022.720699][ T2556] Call Trace:<br /> [ 1022.720984][ T2556] <br /> [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M<br /> [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0<br /> [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30<br /> [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80<br /> [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300<br /> [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0<br /> [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0<br /> [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10<br /> [ 1022.724386][ T2556] kthread+0xfd/0x130<br /> [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10<br /> [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50<br /> [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10<br /> [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30<br /> [ 1022.726201][ T2556] <br /> <br /> To fix we add an skb_get() before passing the skb to be enqueued in the<br /> engress queue. This bumps the skb-&gt;users refcnt so that consume_skb()<br /> and kfree_skb will not immediately free the sk_buff. With this we can<br /> be sure the skb is still around when we do the dequeue. Then we just<br /> need to decrement the refcnt or free the skb in the backlog case which<br /> we do by calling kfree_skb() on the ingress case as well as the sendmsg<br /> case.<br /> <br /> Before locking change from fixes tag we had the sock locked so we<br /> couldn&amp;#39;t race with user and there was no issue here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block/rq_qos: protect rq_qos apis with a new lock<br /> <br /> commit 50e34d78815e ("block: disable the elevator int del_gendisk")<br /> move rq_qos_exit() from disk_release() to del_gendisk(), this will<br /> introduce some problems:<br /> <br /> 1) If rq_qos_add() is triggered by enabling iocost/iolatency through<br /> cgroupfs, then it can concurrent with del_gendisk(), it&amp;#39;s not safe to<br /> write &amp;#39;q-&gt;rq_qos&amp;#39; concurrently.<br /> <br /> 2) Activate cgroup policy that is relied on rq_qos will call<br /> rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is<br /> called in the middle, null-ptr-dereference will be triggered in<br /> blkcg_activate_policy().<br /> <br /> 3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the<br /> disk, then if rq_qos_exit() from del_gendisk() is done before<br /> rq_qos_add(), then memory will be leaked.<br /> <br /> This patch add a new disk level mutex &amp;#39;rq_qos_mutex&amp;#39;:<br /> <br /> 1) The lock will protect rq_qos_exit() directly.<br /> <br /> 2) For wbt that doesn&amp;#39;t relied on blk-cgroup, rq_qos_add() can only be<br /> called from disk initialization for now because wbt can&amp;#39;t be<br /> destructed until rq_qos_exit(), so it&amp;#39;s safe not to protect wbt for<br /> now. Hoever, in case that rq_qos dynamically destruction is supported<br /> in the furture, this patch also protect rq_qos_add() from wbt_init()<br /> directly, this is enough because blk-sysfs already synchronize<br /> writers with disk removal.<br /> <br /> 3) For iocost and iolatency, in order to synchronize disk removal and<br /> cgroup configuration, the lock is held after blkdev_get_no_open()<br /> from blkg_conf_open_bdev(), and is released in blkg_conf_exit().<br /> In order to fix the above memory leak, disk_live() is checked after<br /> holding the new lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: annotate lockless accesses to nlk-&gt;max_recvmsg_len<br /> <br /> syzbot reported a data-race in data-race in netlink_recvmsg() [1]<br /> <br /> Indeed, netlink_recvmsg() can be run concurrently,<br /> and netlink_dump() also needs protection.<br /> <br /> [1]<br /> BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg<br /> <br /> read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:<br /> netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988<br /> sock_recvmsg_nosec net/socket.c:1017 [inline]<br /> sock_recvmsg net/socket.c:1038 [inline]<br /> __sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194<br /> __do_sys_recvfrom net/socket.c:2212 [inline]<br /> __se_sys_recvfrom net/socket.c:2208 [inline]<br /> __x64_sys_recvfrom+0x78/0x90 net/socket.c:2208<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:<br /> netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989<br /> sock_recvmsg_nosec net/socket.c:1017 [inline]<br /> sock_recvmsg net/socket.c:1038 [inline]<br /> ____sys_recvmsg+0x156/0x310 net/socket.c:2720<br /> ___sys_recvmsg net/socket.c:2762 [inline]<br /> do_recvmmsg+0x2e5/0x710 net/socket.c:2856<br /> __sys_recvmmsg net/socket.c:2935 [inline]<br /> __do_sys_recvmmsg net/socket.c:2958 [inline]<br /> __se_sys_recvmmsg net/socket.c:2951 [inline]<br /> __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x0000000000000000 -&gt; 0x0000000000001000<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().<br /> <br /> syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720<br /> ("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it by<br /> updating kcm_tx_msg(head)-&gt;last_skb if partial data is copied so that the<br /> following sendmsg() will resume from the skb.<br /> <br /> However, we cannot know how many bytes were copied when we get the error.<br /> Thus, we could mess up the MSG_MORE queue.<br /> <br /> When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as we<br /> do so for UDP by udp_flush_pending_frames().<br /> <br /> Even without this change, when the error occurred, the following sendmsg()<br /> resumed from a wrong skb and the queue was messed up. However, we have<br /> yet to get such a report, and only syzkaller stumbled on it. So, this<br /> can be changed safely.<br /> <br /> Note this does not change SOCK_SEQPACKET behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show()<br /> <br /> Wear-leveling entry could be freed in error path, which may be accessed<br /> again in eraseblk_count_seq_show(), for example:<br /> <br /> __erase_worker eraseblk_count_seq_show<br /> wl = ubi-&gt;lookuptbl[*block_number]<br /> if (wl)<br /> wl_entry_destroy<br /> ubi-&gt;lookuptbl[e-&gt;pnum] = NULL<br /> kmem_cache_free(ubi_wl_entry_slab, e)<br /> erase_count = wl-&gt;ec // UAF!<br /> <br /> Wear-leveling entry updating/accessing in ubi-&gt;lookuptbl should be<br /> protected by ubi-&gt;wl_lock, fix it by adding ubi-&gt;wl_lock to serialize<br /> wl entry accessing between wl_entry_destroy() and<br /> eraseblk_count_seq_show().<br /> <br /> Fetch a reproducer in [Link].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp}<br /> <br /> Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free<br /> caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to<br /> prevent referencing a channel that is about to be destroyed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()<br /> <br /> KSAN reports use-after-free in hci_add_adv_monitor().<br /> <br /> While adding an adv monitor,<br /> hci_add_adv_monitor() calls -&gt;<br /> msft_add_monitor_pattern() calls -&gt;<br /> msft_add_monitor_sync() calls -&gt;<br /> msft_le_monitor_advertisement_cb() calls in an error case -&gt;<br /> hci_free_adv_monitor() which frees the *moniter.<br /> <br /> This is referenced by bt_dev_dbg() in hci_add_adv_monitor().<br /> <br /> Fix the bt_dev_dbg() by using handle instead of monitor-&gt;handle.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: flush inode if atomic file is aborted<br /> <br /> Let&amp;#39;s flush the inode being aborted atomic operation to avoid stale dirty<br /> inode during eviction in this call stack:<br /> <br /> f2fs_mark_inode_dirty_sync+0x22/0x40 [f2fs]<br /> f2fs_abort_atomic_write+0xc4/0xf0 [f2fs]<br /> f2fs_evict_inode+0x3f/0x690 [f2fs]<br /> ? sugov_start+0x140/0x140<br /> evict+0xc3/0x1c0<br /> evict_inodes+0x17b/0x210<br /> generic_shutdown_super+0x32/0x120<br /> kill_block_super+0x21/0x50<br /> deactivate_locked_super+0x31/0x90<br /> cleanup_mnt+0x100/0x160<br /> task_work_run+0x59/0x90<br /> do_exit+0x33b/0xa50<br /> do_group_exit+0x2d/0x80<br /> __x64_sys_exit_group+0x14/0x20<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This triggers f2fs_bug_on() in f2fs_evict_inode:<br /> f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE));<br /> <br /> This fixes the syzbot report:<br /> <br /> loop0: detected capacity change from 0 to 131072<br /> F2FS-fs (loop0): invalid crc value<br /> F2FS-fs (loop0): Found nat_bits in checkpoint<br /> F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/inode.c:869!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 5014 Comm: syz-executor220 Not tainted 6.4.0-syzkaller-11479-g6cd06ab12d1a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> RIP: 0010:f2fs_evict_inode+0x172d/0x1e00 fs/f2fs/inode.c:869<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc<br /> RSP: 0018:ffffc90003a6fa00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff8880273b8000 RSI: ffffffff83a2bd0d RDI: 0000000000000007<br /> RBP: ffff888077db91b0 R08: 0000000000000007 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff888029a3c000<br /> R13: ffff888077db9660 R14: ffff888029a3c0b8 R15: ffff888077db9c50<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1909bb9000 CR3: 00000000276a9000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> evict+0x2ed/0x6b0 fs/inode.c:665<br /> dispose_list+0x117/0x1e0 fs/inode.c:698<br /> evict_inodes+0x345/0x440 fs/inode.c:748<br /> generic_shutdown_super+0xaf/0x480 fs/super.c:478<br /> kill_block_super+0x64/0xb0 fs/super.c:1417<br /> kill_f2fs_super+0x2af/0x3c0 fs/f2fs/super.c:4704<br /> deactivate_locked_super+0x98/0x160 fs/super.c:330<br /> deactivate_super+0xb1/0xd0 fs/super.c:361<br /> cleanup_mnt+0x2ae/0x3d0 fs/namespace.c:1254<br /> task_work_run+0x16f/0x270 kernel/task_work.c:179<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0xa9a/0x29a0 kernel/exit.c:874<br /> do_group_exit+0xd4/0x2a0 kernel/exit.c:1024<br /> __do_sys_exit_group kernel/exit.c:1035 [inline]<br /> __se_sys_exit_group kernel/exit.c:1033 [inline]<br /> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1033<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f309be71a09<br /> Code: Unable to access opcode bytes at 0x7f309be719df.<br /> RSP: 002b:00007fff171df518 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00007f309bef7330 RCX: 00007f309be71a09<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 00007f309bef1e40<br /> R10: 0000000000010600 R11: 0000000000000246 R12: 00007f309bef7330<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:f2fs_evict_inode+0x172d/0x1e00 fs/f2fs/inode.c:869<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc<br /> RSP: 0018:ffffc90003a6fa00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: think-lmi: Fix memory leak when showing current settings<br /> <br /> When retriving a item string with tlmi_setting(), the result has to be<br /> freed using kfree(). In current_value_show() however, malformed<br /> item strings are not freed, causing a memory leak.<br /> Fix this by eliminating the early return responsible for this.