Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Release folio lock on fscache read hit.<br /> <br /> Under the current code, when cifs_readpage_worker is called, the call<br /> contract is that the callee should unlock the page. This is documented<br /> in the read_folio section of Documentation/filesystems/vfs.rst as:<br /> <br /> &gt; The filesystem should unlock the folio once the read has completed,<br /> &gt; whether it was successful or not.<br /> <br /> Without this change, when fscache is in use and cache hit occurs during<br /> a read, the page lock is leaked, producing the following stack on<br /> subsequent reads (via mmap) to the page:<br /> <br /> $ cat /proc/3890/task/12864/stack<br /> [] folio_wait_bit_common+0x124/0x350<br /> [] filemap_read_folio+0xad/0xf0<br /> [] filemap_fault+0x8b1/0xab0<br /> [] __do_fault+0x39/0x150<br /> [] do_fault+0x25c/0x3e0<br /> [] __handle_mm_fault+0x6ca/0xc70<br /> [] handle_mm_fault+0xe9/0x350<br /> [] do_user_addr_fault+0x225/0x6c0<br /> [] exc_page_fault+0x84/0x1b0<br /> [] asm_exc_page_fault+0x27/0x30<br /> <br /> This requires a reboot to resolve; it is a deadlock.<br /> <br /> Note however that the call to cifs_readpage_from_fscache does mark the<br /> page clean, but does not free the folio lock. This happens in<br /> __cifs_readpage_from_fscache on success. Releasing the lock at that<br /> point however is not appropriate as cifs_readahead also calls<br /> cifs_readpage_from_fscache and *does* unconditionally release the lock<br /> after its return. This change therefore effectively makes<br /> cifs_readpage_worker work like cifs_readahead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix resource leak in device_add()<br /> <br /> When calling kobject_add() failed in device_add(), it will call<br /> cleanup_glue_dir() to free resource. But in kobject_add(),<br /> dev-&gt;kobj.parent has been set to NULL. This will cause resource leak.<br /> <br /> The process is as follows:<br /> device_add()<br /> get_device_parent()<br /> class_dir_create_and_add()<br /> kobject_add() //kobject_get()<br /> ...<br /> dev-&gt;kobj.parent = kobj;<br /> ...<br /> kobject_add() //failed, but set dev-&gt;kobj.parent = NULL<br /> ...<br /> glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto<br /> //"Error" label<br /> ...<br /> cleanup_glue_dir() //becaues glue_dir is NULL, not call<br /> //kobject_put()<br /> <br /> The preceding problem may cause insmod mac80211_hwsim.ko to failed.<br /> sysfs: cannot create duplicate filename &amp;#39;/devices/virtual/mac80211_hwsim&amp;#39;<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> sysfs_warn_dup.cold+0x1c/0x29<br /> sysfs_create_dir_ns+0x224/0x280<br /> kobject_add_internal+0x2aa/0x880<br /> kobject_add+0x135/0x1a0<br /> get_device_parent+0x3d7/0x590<br /> device_add+0x2aa/0x1cb0<br /> device_create_groups_vargs+0x1eb/0x260<br /> device_create+0xdc/0x110<br /> mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]<br /> init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]<br /> do_one_initcall+0x10f/0x630<br /> do_init_module+0x19f/0x5e0<br /> load_module+0x64b7/0x6eb0<br /> __do_sys_finit_module+0x140/0x200<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don&amp;#39;t try to<br /> register things with the same name in the same directory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()<br /> <br /> Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the<br /> perf_sample_event_took() function was added to report time spent in<br /> overflow interrupts. If the interrupt takes too long, the perf framework<br /> will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.<br /> When hwc-&gt;interrupts is larger than max_samples_per_tick, the<br /> hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be<br /> throttled within the __perf_event_account_interrupt() function.<br /> <br /> However, the RISC-V PMU driver doesn&amp;#39;t call riscv_pmu_stop() to update the<br /> PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()<br /> function to avoid throttling. When the perf framework unthrottled the event<br /> in the timer interrupt handler, it triggers riscv_pmu_start() function<br /> and causes a WARN_ON_ONCE() warning, as shown below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e<br /> Modules linked in:<br /> CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1<br /> Hardware name: SiFive (DT)<br /> epc : riscv_pmu_start+0x7c/0x8e<br /> ra : riscv_pmu_start+0x28/0x8e<br /> epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0<br /> gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0<br /> t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720<br /> s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000<br /> a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000<br /> a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030<br /> s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00<br /> s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000<br /> s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340<br /> s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796<br /> t5 : 0000000700000000 t6 : ffffaf8005269870<br /> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [] riscv_pmu_start+0x7c/0x8e<br /> [] perf_adjust_freq_unthr_context+0x15e/0x174<br /> [] perf_event_task_tick+0x88/0x9c<br /> [] scheduler_tick+0xfe/0x27c<br /> [] update_process_times+0x9a/0xba<br /> [] tick_sched_handle+0x32/0x66<br /> [] tick_sched_timer+0x64/0xb0<br /> [] __hrtimer_run_queues+0x156/0x2f4<br /> [] hrtimer_interrupt+0xe2/0x1fe<br /> [] riscv_timer_interrupt+0x38/0x42<br /> [] handle_percpu_devid_irq+0x90/0x1d2<br /> [] generic_handle_domain_irq+0x28/0x36<br /> <br /> After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,<br /> they don&amp;#39;t call *_pmu_stop() to update with PERF_HES_STOPPED flag<br /> after perf_event_overflow() function nor do they add PERF_HES_STOPPED<br /> flag checking in *_pmu_start() which don&amp;#39;t cause this warning.<br /> <br /> Thus, it&amp;#39;s recommended to remove this unnecessary check in<br /> riscv_pmu_start() function to prevent this warning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process<br /> <br /> There are two states for ubifs writing pages:<br /> 1. Dirty, Private<br /> 2. Not Dirty, Not Private<br /> <br /> The normal process cannot go to ubifs_releasepage() which means there<br /> exists pages being private but not dirty. Reproducer[1] shows that it<br /> could occur (which maybe related to [2]) with following process:<br /> <br /> PA PB PC<br /> lock(page)[PA]<br /> ubifs_write_end<br /> attach_page_private // set Private<br /> __set_page_dirty_nobuffers // set Dirty<br /> unlock(page)<br /> <br /> write_cache_pages[PA]<br /> lock(page)<br /> clear_page_dirty_for_io(page) // clear Dirty<br /> ubifs_writepage<br /> <br /> do_truncation[PB]<br /> truncate_setsize<br /> i_size_write(inode, newsize) // newsize = 0<br /> <br /> i_size = i_size_read(inode) // i_size = 0<br /> end_index = i_size &gt;&gt; PAGE_SHIFT<br /> if (page-&gt;index &gt; end_index)<br /> goto out // jump<br /> out:<br /> unlock(page) // Private, Not Dirty<br /> <br /> generic_fadvise[PC]<br /> lock(page)<br /> invalidate_inode_page<br /> try_to_release_page<br /> ubifs_releasepage<br /> ubifs_assert(c, 0)<br /> // bad assertion!<br /> unlock(page)<br /> truncate_pagecache[PB]<br /> <br /> Then we may get following assertion failed:<br /> UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:<br /> UBIFS assert failed: 0, in fs/ubifs/file.c:1513<br /> UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:<br /> switched to read-only mode, error -22<br /> CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308<br /> Call Trace:<br /> dump_stack+0x13/0x1b<br /> ubifs_ro_mode+0x54/0x60 [ubifs]<br /> ubifs_assert_failed+0x4b/0x80 [ubifs]<br /> ubifs_releasepage+0x67/0x1d0 [ubifs]<br /> try_to_release_page+0x57/0xe0<br /> invalidate_inode_page+0xfb/0x130<br /> __invalidate_mapping_pages+0xb9/0x280<br /> invalidate_mapping_pagevec+0x12/0x20<br /> generic_fadvise+0x303/0x3c0<br /> ksys_fadvise64_64+0x4c/0xb0<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=215373<br /> [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject unhashed sockets in bpf_sk_assign<br /> <br /> The semantics for bpf_sk_assign are as follows:<br /> <br /> sk = some_lookup_func()<br /> bpf_sk_assign(skb, sk)<br /> bpf_sk_release(sk)<br /> <br /> That is, the sk is not consumed by bpf_sk_assign. The function<br /> therefore needs to make sure that sk lives long enough to be<br /> consumed from __inet_lookup_skb. The path through the stack for a<br /> TCPv4 packet is roughly:<br /> <br /> netif_receive_skb_core: takes RCU read lock<br /> __netif_receive_skb_core:<br /> sch_handle_ingress:<br /> tcf_classify:<br /> bpf_sk_assign()<br /> deliver_ptype_list_skb:<br /> deliver_skb:<br /> ip_packet_type-&gt;func == ip_rcv:<br /> ip_rcv_core:<br /> ip_rcv_finish_core:<br /> dst_input:<br /> ip_local_deliver:<br /> ip_local_deliver_finish:<br /> ip_protocol_deliver_rcu:<br /> tcp_v4_rcv:<br /> __inet_lookup_skb:<br /> skb_steal_sock<br /> <br /> The existing helper takes advantage of the fact that everything<br /> happens in the same RCU critical section: for sockets with<br /> SOCK_RCU_FREE set bpf_sk_assign never takes a reference.<br /> skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put<br /> if necessary.<br /> <br /> This approach assumes that SOCK_RCU_FREE is never set on a sk<br /> between bpf_sk_assign and skb_steal_sock, but this invariant is<br /> violated by unhashed UDP sockets. A new UDP socket is created<br /> in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only<br /> added in udp_lib_get_port() which happens when a socket is bound.<br /> <br /> When bpf_sk_assign was added it wasn&amp;#39;t possible to access unhashed<br /> UDP sockets from BPF, so this wasn&amp;#39;t a problem. This changed<br /> in commit 0c48eefae712 ("sock_map: Lift socket state restriction<br /> for datagram sockets"), but the helper wasn&amp;#39;t adjusted accordingly.<br /> The following sequence of events will therefore lead to a refcount<br /> leak:<br /> <br /> 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.<br /> 2. Pull socket out of sockmap and bpf_sk_assign it. Since<br /> SOCK_RCU_FREE is not set we increment the refcount.<br /> 3. bind() or connect() the socket, setting SOCK_RCU_FREE.<br /> 4. skb_steal_sock will now set refcounted = false due to<br /> SOCK_RCU_FREE.<br /> 5. tcp_v4_rcv() skips sock_put().<br /> <br /> Fix the problem by rejecting unhashed sockets in bpf_sk_assign().<br /> This matches the behaviour of __inet_lookup_skb which is ultimately<br /> the goal of bpf_sk_assign().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix multiple LUN_RESET handling<br /> <br /> This fixes a bug where an initiator thinks a LUN_RESET has cleaned up<br /> running commands when it hasn&amp;#39;t. The bug was added in commit 51ec502a3266<br /> ("target: Delete tmr from list before processing").<br /> <br /> The problem occurs when:<br /> <br /> 1. We have N I/O cmds running in the target layer spread over 2 sessions.<br /> <br /> 2. The initiator sends a LUN_RESET for each session.<br /> <br /> 3. session1&amp;#39;s LUN_RESET loops over all the running commands from both<br /> sessions and moves them to its local drain_task_list.<br /> <br /> 4. session2&amp;#39;s LUN_RESET does not see the LUN_RESET from session1 because<br /> the commit above has it remove itself. session2 also does not see any<br /> commands since the other reset moved them off the state lists.<br /> <br /> 5. sessions2&amp;#39;s LUN_RESET will then complete with a successful response.<br /> <br /> 6. sessions2&amp;#39;s inititor believes the running commands on its session are<br /> now cleaned up due to the successful response and cleans up the running<br /> commands from its side. It then restarts them.<br /> <br /> 7. The commands do eventually complete on the backend and the target<br /> starts to return aborted task statuses for them. The initiator will<br /> either throw a invalid ITT error or might accidentally lookup a new<br /> task if the ITT has been reallocated already.<br /> <br /> Fix the bug by reverting the patch, and serialize the execution of<br /> LUN_RESETs and Preempt and Aborts.<br /> <br /> Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,<br /> because it turns out the original patch fixed a bug that was not<br /> mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second<br /> LUN_RESET and wait on it. Then the second reset will run<br /> core_tmr_drain_tmr_list and see the first reset and wait on it resulting in<br /> a deadlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: delete timer and free skb queue when unloading<br /> <br /> Fix possible crash and memory leak on driver unload by deleting<br /> TX purge timer and freeing C2H queue in &amp;#39;rtw_core_deinit()&amp;#39;,<br /> shrink critical section in the latter by freeing COEX queue<br /> out of TX report lock scope.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix potential array out of bounds access<br /> <br /> Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying<br /> key_len size in iwl_mvm_sec_key_add().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: Always check queue mode setting from configfs<br /> <br /> Make sure to check device queue mode in the null_validate_conf() and<br /> return error for NULL_Q_RQ as we don&amp;#39;t allow legacy I/O path, without<br /> this patch we get OOPs when queue mode is set to 1 from configfs,<br /> following are repro steps :-<br /> <br /> modprobe null_blk nr_devices=0<br /> mkdir config/nullb/nullb0<br /> echo 1 &gt; config/nullb/nullb0/memory_backed<br /> echo 4096 &gt; config/nullb/nullb0/blocksize<br /> echo 20480 &gt; config/nullb/nullb0/size<br /> echo 1 &gt; config/nullb/nullb0/queue_mode<br /> echo 1 &gt; config/nullb/nullb0/power<br /> <br /> Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)<br /> due to oops @ 0xffffffffc041c329<br /> CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]<br /> Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20<br /> RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00<br /> RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740<br /> FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0<br /> DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a<br /> DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> nullb_device_power_store+0xd1/0x120 [null_blk]<br /> configfs_write_iter+0xb4/0x120<br /> vfs_write+0x2ba/0x3c0<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7fd4460c57a7<br /> Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7<br /> RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001<br /> RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0<br /> R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002<br /> R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cpumap: Make sure kthread is running before map update returns<br /> <br /> The following warning was reported when running stress-mode enabled<br /> xdp_redirect_cpu with some RT threads:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135<br /> CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: events cpu_map_kthread_stop<br /> RIP: 0010:put_cpu_map_entry+0xda/0x220<br /> ......<br /> Call Trace:<br /> <br /> ? show_regs+0x65/0x70<br /> ? __warn+0xa5/0x240<br /> ......<br /> ? put_cpu_map_entry+0xda/0x220<br /> cpu_map_kthread_stop+0x41/0x60<br /> process_one_work+0x6b0/0xb80<br /> worker_thread+0x96/0x720<br /> kthread+0x1a5/0x1f0<br /> ret_from_fork+0x3a/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory<br /> leak in cpu_map_update_elem"). The kthread is stopped prematurely by<br /> kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn&amp;#39;t call<br /> cpu_map_kthread_run() at all but XDP program has already queued some<br /> frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks<br /> the ptr_ring, it will find it was not emptied and report a warning.<br /> <br /> An alternative fix is to use __cpu_map_ring_cleanup() to drop these<br /> pending frames or skbs when kthread_stop() returns -EINTR, but it may<br /> confuse the user, because these frames or skbs have been handled<br /> correctly by XDP program. So instead of dropping these frames or skbs,<br /> just make sure the per-cpu kthread is running before<br /> __cpu_map_entry_alloc() returns.<br /> <br /> After apply the fix, the error handle for kthread_stop() will be<br /> unnecessary because it will always return 0, so just remove it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630<br /> qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because that skb-&gt;len requires at least sizeof(struct qrtr_ctrl_pkt)<br /> in qrtr_tx_resume(). And skb-&gt;len equals to size in qrtr_endpoint_post().<br /> But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb-&gt;type<br /> equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot<br /> scenario. This triggers the uninit variable access bug.<br /> <br /> Add size check when qrtr_cb-&gt;type equals to QRTR_TYPE_RESUME_TX in<br /> qrtr_endpoint_post() to fix the bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mvebu: fix irq domain leak<br /> <br /> Uwe Kleine-König pointed out we still have one resource leak in the mvebu<br /> driver triggered on driver detach. Let&amp;#39;s address it with a custom devm<br /> action.