Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()<br /> <br /> When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),<br /> overlay plane&amp;#39;s framebuffer pointer is NULL. So, dereferencing it would<br /> cause a kernel Oops(NULL pointer dereferencing). Fix the issue by<br /> disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix warning when putting transaction with qgroups enabled after abort<br /> <br /> If we have a transaction abort with qgroups enabled we get a warning<br /> triggered when doing the final put on the transaction, like this:<br /> <br /> [552.6789] ------------[ cut here ]------------<br /> [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6817] Modules linked in: btrfs blake2b_generic xor (...)<br /> [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6821] Code: bd a0 01 00 (...)<br /> [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286<br /> [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000<br /> [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010<br /> [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20<br /> [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70<br /> [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028<br /> [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000<br /> [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0<br /> [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [552.6822] Call Trace:<br /> [552.6822] <br /> [552.6822] ? __warn+0x80/0x130<br /> [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6824] ? report_bug+0x1f4/0x200<br /> [552.6824] ? handle_bug+0x42/0x70<br /> [552.6824] ? exc_invalid_op+0x14/0x70<br /> [552.6824] ? asm_exc_invalid_op+0x16/0x20<br /> [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs]<br /> [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40<br /> [552.6828] ? try_to_wake_up+0x94/0x5e0<br /> [552.6828] ? __pfx_process_timeout+0x10/0x10<br /> [552.6828] transaction_kthread+0x103/0x1d0 [btrfs]<br /> [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs]<br /> [552.6832] kthread+0xee/0x120<br /> [552.6832] ? __pfx_kthread+0x10/0x10<br /> [552.6832] ret_from_fork+0x29/0x50<br /> [552.6832] <br /> [552.6832] ---[ end trace 0000000000000000 ]---<br /> <br /> This corresponds to this line of code:<br /> <br /> void btrfs_put_transaction(struct btrfs_transaction *transaction)<br /> {<br /> (...)<br /> WARN_ON(!RB_EMPTY_ROOT(<br /> &amp;transaction-&gt;delayed_refs.dirty_extent_root));<br /> (...)<br /> }<br /> <br /> The warning happens because btrfs_qgroup_destroy_extent_records(), called<br /> in the transaction abort path, we free all entries from the rbtree<br /> "dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but we<br /> don&amp;#39;t actually empty the rbtree - it&amp;#39;s still pointing to nodes that were<br /> freed.<br /> <br /> So set the rbtree&amp;#39;s root node to NULL to avoid this warning (assign<br /> RB_ROOT).

*** Pendiente de traducción *** EDK2 contains a vulnerability in BIOS where an attacker may cause “Exposure of Sensitive Information to an Unauthorized Actor” by local access. Successful exploitation of this vulnerability will lead to <br /> <br /> possible information disclosure or escalation of privilege<br /> <br /> and impact Confidentiality.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8186: Fix use-after-free in driver remove path<br /> <br /> When devm runs function in the "remove" path for a device it runs them<br /> in the reverse order. That means that if you have parts of your driver<br /> that aren&amp;#39;t using devm or are using "roll your own" devm w/<br /> devm_add_action_or_reset() you need to keep that in mind.<br /> <br /> The mt8186 audio driver didn&amp;#39;t quite get this right. Specifically, in<br /> mt8186_init_clock() it called mt8186_audsys_clk_register() and then<br /> went on to call a bunch of other devm function. The caller of<br /> mt8186_init_clock() used devm_add_action_or_reset() to call<br /> mt8186_deinit_clock() but, because of the intervening devm functions,<br /> the order was wrong.<br /> <br /> Specifically at probe time, the order was:<br /> 1. mt8186_audsys_clk_register()<br /> 2. afe_priv-&gt;clk = devm_kcalloc(...)<br /> 3. afe_priv-&gt;clk[i] = devm_clk_get(...)<br /> <br /> At remove time, the order (which should have been 3, 2, 1) was:<br /> 1. mt8186_audsys_clk_unregister()<br /> 3. Free all of afe_priv-&gt;clk[i]<br /> 2. Free afe_priv-&gt;clk<br /> <br /> The above seemed to be causing a use-after-free. Luckily, it&amp;#39;s easy to<br /> fix this by simply using devm more correctly. Let&amp;#39;s move the<br /> devm_add_action_or_reset() to the right place. In addition to fixing<br /> the use-after-free, code inspection shows that this fixes a leak<br /> (missing call to mt8186_audsys_clk_unregister()) that would have<br /> happened if any of the syscon_regmap_lookup_by_phandle() calls in<br /> mt8186_init_clock() had failed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver remove<br /> <br /> When the tagging protocol in current use is "ocelot-8021q" and we unbind<br /> the driver, we see this splat:<br /> <br /> $ echo &amp;#39;0000:00:00.2&amp;#39; &gt; /sys/bus/pci/drivers/fsl_enetc/unbind<br /> mscc_felix 0000:00:00.5 swp0: left promiscuous mode<br /> sja1105 spi2.0: Link is Down<br /> DSA: tree 1 torn down<br /> mscc_felix 0000:00:00.5 swp2: left promiscuous mode<br /> sja1105 spi2.2: Link is Down<br /> DSA: tree 3 torn down<br /> fsl_enetc 0000:00:00.2 eno2: left promiscuous mode<br /> mscc_felix 0000:00:00.5: Link is Down<br /> ------------[ cut here ]------------<br /> RTNL: assertion failed at net/dsa/tag_8021q.c (409)<br /> WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0<br /> Modules linked in:<br /> CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771<br /> pc : dsa_tag_8021q_unregister+0x12c/0x1a0<br /> lr : dsa_tag_8021q_unregister+0x12c/0x1a0<br /> Call trace:<br /> dsa_tag_8021q_unregister+0x12c/0x1a0<br /> felix_tag_8021q_teardown+0x130/0x150<br /> felix_teardown+0x3c/0xd8<br /> dsa_tree_teardown_switches+0xbc/0xe0<br /> dsa_unregister_switch+0x168/0x260<br /> felix_pci_remove+0x30/0x60<br /> pci_device_remove+0x4c/0x100<br /> device_release_driver_internal+0x188/0x288<br /> device_links_unbind_consumers+0xfc/0x138<br /> device_release_driver_internal+0xe0/0x288<br /> device_driver_detach+0x24/0x38<br /> unbind_store+0xd8/0x108<br /> drv_attr_store+0x30/0x50<br /> ---[ end trace 0000000000000000 ]---<br /> ------------[ cut here ]------------<br /> RTNL: assertion failed at net/8021q/vlan_core.c (376)<br /> WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0<br /> CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771<br /> pc : vlan_vid_del+0x1b8/0x1f0<br /> lr : vlan_vid_del+0x1b8/0x1f0<br /> dsa_tag_8021q_unregister+0x8c/0x1a0<br /> felix_tag_8021q_teardown+0x130/0x150<br /> felix_teardown+0x3c/0xd8<br /> dsa_tree_teardown_switches+0xbc/0xe0<br /> dsa_unregister_switch+0x168/0x260<br /> felix_pci_remove+0x30/0x60<br /> pci_device_remove+0x4c/0x100<br /> device_release_driver_internal+0x188/0x288<br /> device_links_unbind_consumers+0xfc/0x138<br /> device_release_driver_internal+0xe0/0x288<br /> device_driver_detach+0x24/0x38<br /> unbind_store+0xd8/0x108<br /> drv_attr_store+0x30/0x50<br /> DSA: tree 0 torn down<br /> <br /> This was somewhat not so easy to spot, because "ocelot-8021q" is not the<br /> default tagging protocol, and thus, not everyone who tests the unbinding<br /> path may have switched to it beforehand. The default<br /> felix_tag_npi_teardown() does not require rtnl_lock() to be held.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: overlay: Call of_changeset_init() early<br /> <br /> When of_overlay_fdt_apply() fails, the changeset may be partially<br /> applied, and the caller is still expected to call of_overlay_remove() to<br /> clean up this partial state.<br /> <br /> However, of_overlay_apply() calls of_resolve_phandles() before<br /> init_overlay_changeset(). Hence if the overlay fails to apply due to an<br /> unresolved symbol, the overlay_changeset.cset.entries list is still<br /> uninitialized, and cleanup will crash with a NULL-pointer dereference in<br /> overlay_removal_is_ok().<br /> <br /> Fix this by moving the call to of_changeset_init() from<br /> init_overlay_changeset() to of_overlay_fdt_apply(), where all other<br /> early initialization is done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: bpf_sk_storage: Fix invalid wait context lockdep report<br /> <br /> &amp;#39;./test_progs -t test_local_storage&amp;#39; reported a splat:<br /> <br /> [ 27.137569] =============================<br /> [ 27.138122] [ BUG: Invalid wait context ]<br /> [ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O<br /> [ 27.139542] -----------------------------<br /> [ 27.140106] test_progs/1729 is trying to lock:<br /> [ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130<br /> [ 27.141834] other info that might help us debug this:<br /> [ 27.142437] context-{5:5}<br /> [ 27.142856] 2 locks held by test_progs/1729:<br /> [ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40<br /> [ 27.144492] #1: ffff888107deb2c0 (&amp;storage-&gt;lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0<br /> [ 27.145855] stack backtrace:<br /> [ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247<br /> [ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 27.149127] Call Trace:<br /> [ 27.149490] <br /> [ 27.149867] dump_stack_lvl+0x130/0x1d0<br /> [ 27.152609] dump_stack+0x14/0x20<br /> [ 27.153131] __lock_acquire+0x1657/0x2220<br /> [ 27.153677] lock_acquire+0x1b8/0x510<br /> [ 27.157908] local_lock_acquire+0x29/0x130<br /> [ 27.159048] obj_cgroup_charge+0xf4/0x3c0<br /> [ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0<br /> [ 27.161931] __kmem_cache_alloc_node+0x51/0x210<br /> [ 27.163557] __kmalloc+0xaa/0x210<br /> [ 27.164593] bpf_map_kzalloc+0xbc/0x170<br /> [ 27.165147] bpf_selem_alloc+0x130/0x510<br /> [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0<br /> [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0<br /> [ 27.169199] bpf_map_update_value+0x415/0x4f0<br /> [ 27.169871] map_update_elem+0x413/0x550<br /> [ 27.170330] __sys_bpf+0x5e9/0x640<br /> [ 27.174065] __x64_sys_bpf+0x80/0x90<br /> [ 27.174568] do_syscall_64+0x48/0xa0<br /> [ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 27.175932] RIP: 0033:0x7effb40e41ad<br /> [ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d8<br /> [ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141<br /> [ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad<br /> [ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002<br /> [ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788<br /> [ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000<br /> [ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000<br /> [ 27.184958] <br /> <br /> It complains about acquiring a local_lock while holding a raw_spin_lock.<br /> It means it should not allocate memory while holding a raw_spin_lock<br /> since it is not safe for RT.<br /> <br /> raw_spin_lock is needed because bpf_local_storage supports tracing<br /> context. In particular for task local storage, it is easy to<br /> get a "current" task PTR_TO_BTF_ID in tracing bpf prog.<br /> However, task (and cgroup) local storage has already been moved to<br /> bpf mem allocator which can be used after raw_spin_lock.<br /> <br /> The splat is for the sk storage. For sk (and inode) storage,<br /> it has not been moved to bpf mem allocator. Using raw_spin_lock or not,<br /> kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.<br /> However, the local storage helper requires a verifier accepted<br /> sk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean running<br /> a bpf prog in a kzalloc unsafe context and also able to hold a verifier<br /> accepted sk pointer) could happen.<br /> <br /> This patch avoids kzalloc after raw_spin_lock to silent the splat.<br /> There is an existing kzalloc before the raw_spin_lock. At that point,<br /> a kzalloc is very likely required because a lookup has just been done<br /> before. Thus, this patch always does the kzalloc before acq<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error<br /> <br /> If clk_get_rate() fails, the clk that has just been allocated needs to be<br /> freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/idle: mark arch_cpu_idle() noinstr<br /> <br /> linux-next commit ("cpuidle: tracing: Warn about !rcu_is_watching()")<br /> adds a new warning which hits on s390&amp;#39;s arch_cpu_idle() function:<br /> <br /> RCU not on for: arch_cpu_idle+0x0/0x28<br /> WARNING: CPU: 2 PID: 0 at include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258<br /> Modules linked in:<br /> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6-next-20230202 #4<br /> Hardware name: IBM 8561 T01 703 (z/VM 7.3.0)<br /> Krnl PSW : 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3<br /> Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000<br /> 0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0<br /> 0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8<br /> Krnl Code: 00000000002b55b0: c02000840051 larl %r2,0000000001335652<br /> 00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58<br /> #00000000002b55bc: af000000 mc 0,0<br /> &gt;00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e<br /> 00000000002b55c4: 0707 bcr 0,%r7<br /> 00000000002b55c6: 0707 bcr 0,%r7<br /> 00000000002b55c8: eb6ff0480024 stmg %r6,%r15,72(%r15)<br /> 00000000002b55ce: b90400ef lgr %r14,%r15<br /> Call Trace:<br /> [] arch_ftrace_ops_list_func+0x250/0x258<br /> ([] arch_ftrace_ops_list_func+0x24c/0x258)<br /> [] ftrace_common+0x1c/0x20<br /> [] arch_cpu_idle+0x6/0x28<br /> [] default_idle_call+0x76/0x128<br /> [] do_idle+0xf4/0x1b0<br /> [] cpu_startup_entry+0x36/0x40<br /> [] smp_start_secondary+0x140/0x150<br /> [] restart_int_handler+0x6e/0x90<br /> <br /> Mark arch_cpu_idle() noinstr like all other architectures with<br /> CONFIG_ARCH_WANTS_NO_INSTR (should) have it to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: don&amp;#39;t attempt to queue IO under RCU protection<br /> <br /> dm looks up the table for IO based on the request type, with an<br /> assumption that if the request is marked REQ_NOWAIT, it&amp;#39;s fine to<br /> attempt to submit that IO while under RCU read lock protection. This<br /> is not OK, as REQ_NOWAIT just means that we should not be sleeping<br /> waiting on other IO, it does not mean that we can&amp;#39;t potentially<br /> schedule.<br /> <br /> A simple test case demonstrates this quite nicely:<br /> <br /> int main(int argc, char *argv[])<br /> {<br /> struct iovec iov;<br /> int fd;<br /> <br /> fd = open("/dev/dm-0", O_RDONLY | O_DIRECT);<br /> posix_memalign(&amp;iov.iov_base, 4096, 4096);<br /> iov.iov_len = 4096;<br /> preadv2(fd, &amp;iov, 1, 0, RWF_NOWAIT);<br /> return 0;<br /> }<br /> <br /> which will instantly spew:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x11d/0x1b0<br /> __might_resched+0x3c3/0x5e0<br /> ? preempt_count_sub+0x150/0x150<br /> mempool_alloc+0x1e2/0x390<br /> ? mempool_resize+0x7d0/0x7d0<br /> ? lock_sync+0x190/0x190<br /> ? lock_release+0x4b7/0x670<br /> ? internal_get_user_pages_fast+0x868/0x2d40<br /> bio_alloc_bioset+0x417/0x8c0<br /> ? bvec_alloc+0x200/0x200<br /> ? internal_get_user_pages_fast+0xb8c/0x2d40<br /> bio_alloc_clone+0x53/0x100<br /> dm_submit_bio+0x27f/0x1a20<br /> ? lock_release+0x4b7/0x670<br /> ? blk_try_enter_queue+0x1a0/0x4d0<br /> ? dm_dax_direct_access+0x260/0x260<br /> ? rcu_is_watching+0x12/0xb0<br /> ? blk_try_enter_queue+0x1cc/0x4d0<br /> __submit_bio+0x239/0x310<br /> ? __bio_queue_enter+0x700/0x700<br /> ? kvm_clock_get_cycles+0x40/0x60<br /> ? ktime_get+0x285/0x470<br /> submit_bio_noacct_nocheck+0x4d9/0xb80<br /> ? should_fail_request+0x80/0x80<br /> ? preempt_count_sub+0x150/0x150<br /> ? lock_release+0x4b7/0x670<br /> ? __bio_add_page+0x143/0x2d0<br /> ? iov_iter_revert+0x27/0x360<br /> submit_bio_noacct+0x53e/0x1b30<br /> submit_bio_wait+0x10a/0x230<br /> ? submit_bio_wait_endio+0x40/0x40<br /> __blkdev_direct_IO_simple+0x4f8/0x780<br /> ? blkdev_bio_end_io+0x4c0/0x4c0<br /> ? stack_trace_save+0x90/0xc0<br /> ? __bio_clone+0x3c0/0x3c0<br /> ? lock_release+0x4b7/0x670<br /> ? lock_sync+0x190/0x190<br /> ? atime_needs_update+0x3bf/0x7e0<br /> ? timestamp_truncate+0x21b/0x2d0<br /> ? inode_owner_or_capable+0x240/0x240<br /> blkdev_direct_IO.part.0+0x84a/0x1810<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> ? blkdev_read_iter+0x40d/0x530<br /> ? reacquire_held_locks+0x4e0/0x4e0<br /> ? __blkdev_direct_IO_simple+0x780/0x780<br /> ? rcu_is_watching+0x12/0xb0<br /> ? __mark_inode_dirty+0x297/0xd50<br /> ? preempt_count_add+0x72/0x140<br /> blkdev_read_iter+0x2a4/0x530<br /> do_iter_readv_writev+0x2f2/0x3c0<br /> ? generic_copy_file_range+0x1d0/0x1d0<br /> ? fsnotify_perm.part.0+0x25d/0x630<br /> ? security_file_permission+0xd8/0x100<br /> do_iter_read+0x31b/0x880<br /> ? import_iovec+0x10b/0x140<br /> vfs_readv+0x12d/0x1a0<br /> ? vfs_iter_read+0xb0/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> do_preadv+0x1b3/0x260<br /> ? do_readv+0x370/0x370<br /> __x64_sys_preadv2+0xef/0x150<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f5af41ad806<br /> Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55<br /> RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806<br /> RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003<br /> RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001<br /> <br /> <br /> where in fact it is<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: correct grp validation in ext4_mb_good_group<br /> <br /> Group corruption check will access memory of grp and will trigger kernel<br /> crash if grp is NULL. So do NULL check before corruption check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix missing hfs_bnode_get() in __hfs_bnode_create<br /> <br /> Syzbot found a kernel BUG in hfs_bnode_put():<br /> <br /> kernel BUG at fs/hfs/bnode.c:466!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 3634 Comm: kworker/u4:5 Not tainted 6.1.0-rc7-syzkaller-00190-g97ee9d1c1696 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> RIP: 0010:hfs_bnode_put+0x46f/0x480 fs/hfs/bnode.c:466<br /> Code: 8a 80 ff e9 73 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a0 fe ff ff 48 89 df e8 db 8a 80 ff e9 93 fe ff ff e8 a1 68 2c ff 0b e8 9a 68 2c ff 0f 0b 0f 1f 84 00 00 00 00 00 55 41 57 41 56<br /> RSP: 0018:ffffc90003b4f258 EFLAGS: 00010293<br /> RAX: ffffffff825e318f RBX: 0000000000000000 RCX: ffff8880739dd7c0<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90003b4f430 R08: ffffffff825e2d9b R09: ffffed10045157d1<br /> R10: ffffed10045157d1 R11: 1ffff110045157d0 R12: ffff8880228abe80<br /> R13: ffff88807016c000 R14: dffffc0000000000 R15: ffff8880228abe00<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa6ebe88718 CR3: 000000001e93d000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> hfs_write_inode+0x1bc/0xb40<br /> write_inode fs/fs-writeback.c:1440 [inline]<br /> __writeback_single_inode+0x4d6/0x670 fs/fs-writeback.c:1652<br /> writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1878<br /> __writeback_inodes_wb+0x125/0x420 fs/fs-writeback.c:1949<br /> wb_writeback+0x440/0x7b0 fs/fs-writeback.c:2054<br /> wb_check_start_all fs/fs-writeback.c:2176 [inline]<br /> wb_do_writeback fs/fs-writeback.c:2202 [inline]<br /> wb_workfn+0x827/0xef0 fs/fs-writeback.c:2235<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> The BUG_ON() is triggered at here:<br /> <br /> /* Dispose of resources used by a node */<br /> void hfs_bnode_put(struct hfs_bnode *node)<br /> {<br /> if (node) {<br /> <br /> BUG_ON(!atomic_read(&amp;node-&gt;refcnt));