Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid use-after-free for cached IPU bio<br /> <br /> xfstest generic/019 reports a bug:<br /> <br /> kernel BUG at mm/filemap.c:1619!<br /> RIP: 0010:folio_end_writeback+0x8a/0x90<br /> Call Trace:<br /> end_page_writeback+0x1c/0x60<br /> f2fs_write_end_io+0x199/0x420<br /> bio_endio+0x104/0x180<br /> submit_bio_noacct+0xa5/0x510<br /> submit_bio+0x48/0x80<br /> f2fs_submit_write_bio+0x35/0x300<br /> f2fs_submit_merged_ipu_write+0x2a0/0x2b0<br /> f2fs_write_single_data_page+0x838/0x8b0<br /> f2fs_write_cache_pages+0x379/0xa30<br /> f2fs_write_data_pages+0x30c/0x340<br /> do_writepages+0xd8/0x1b0<br /> __writeback_single_inode+0x44/0x370<br /> writeback_sb_inodes+0x233/0x4d0<br /> __writeback_inodes_wb+0x56/0xf0<br /> wb_writeback+0x1dd/0x2d0<br /> wb_workfn+0x367/0x4a0<br /> process_one_work+0x21d/0x430<br /> worker_thread+0x4e/0x3c0<br /> kthread+0x103/0x130<br /> ret_from_fork+0x2c/0x50<br /> <br /> The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()<br /> in f2fs_write_single_data_page() tries to flush IPU bio in cache, however<br /> f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,<br /> result in submitting random cached bio which belong to other IO context,<br /> then it will cause use-after-free issue, fix it by adding additional<br /> validity check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-crypto: make blk_crypto_evict_key() more robust<br /> <br /> If blk_crypto_evict_key() sees that the key is still in-use (due to a<br /> bug) or that -&gt;keyslot_evict failed, it currently just returns while<br /> leaving the key linked into the keyslot management structures.<br /> <br /> However, blk_crypto_evict_key() is only called in contexts such as inode<br /> eviction where failure is not an option. So actually the caller<br /> proceeds with freeing the blk_crypto_key regardless of the return value<br /> of blk_crypto_evict_key().<br /> <br /> These two assumptions don&amp;#39;t match, and the result is that there can be a<br /> use-after-free in blk_crypto_reprogram_all_keys() after one of these<br /> errors occurs. (Note, these errors *shouldn&amp;#39;t* happen; we&amp;#39;re just<br /> talking about what happens if they do anyway.)<br /> <br /> Fix this by making blk_crypto_evict_key() unlink the key from the<br /> keyslot management structures even on failure.<br /> <br /> Also improve some comments.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: Add a check for oversized packets<br /> <br /> Occasionnaly we may get oversized packets from the hardware which<br /> exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early<br /> check which drops the packet to avoid invoking skb_over_panic() and move<br /> on to processing the next packet.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc<br /> <br /> As the devm_kcalloc may return NULL, the return value needs to be checked<br /> to avoid NULL poineter dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe<br /> <br /> rpi_firmware_get() take reference, we need to release it in error paths<br /> as well. Use devm_rpi_firmware_get() helper to handling the resources.<br /> Also remove the existing rpi_firmware_put().

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: avoid scheduling in rtas_os_term()<br /> <br /> It&amp;#39;s unsafe to use rtas_busy_delay() to handle a busy status from<br /> the ibm,os-term RTAS function in rtas_os_term():<br /> <br /> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9<br /> Call Trace:<br /> [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)<br /> [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0<br /> [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0<br /> [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4<br /> [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68<br /> [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50<br /> [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0<br /> [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0<br /> [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0<br /> [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420<br /> [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200<br /> <br /> Use rtas_busy_delay_time() instead, which signals without side effects<br /> whether to attempt the ibm,os-term RTAS call again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: lpddr2_nvm: Fix possible null-ptr-deref<br /> <br /> It will cause null-ptr-deref when resource_size(add_range) invoked,<br /> if platform_get_resource() returns NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: coda: Add check for dcoda_iram_alloc<br /> <br /> As the coda_iram_alloc may return NULL pointer,<br /> it should be better to check the return value<br /> in order to avoid NULL poineter dereference,<br /> same as the others.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed<br /> <br /> If some items in nsim_dev_resources_register() fail, memory leak will<br /> occur. The following is the memory leak information.<br /> <br /> unreferenced object 0xffff888074c02600 (size 128):<br /> comm "echo", pid 8159, jiffies 4294945184 (age 493.530s)<br /> hex dump (first 32 bytes):<br /> 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G..............<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x22/0x60<br /> [] devl_resource_register+0x144/0x4e0<br /> [] nsim_drv_probe+0x37a/0x1260<br /> [] really_probe+0x20b/0xb10<br /> [] __driver_probe_device+0x1b3/0x4a0<br /> [] driver_probe_device+0x49/0x140<br /> [] __device_attach_driver+0x18c/0x2a0<br /> [] bus_for_each_drv+0x151/0x1d0<br /> [] __device_attach+0x1c9/0x4e0<br /> [] bus_probe_device+0x1d5/0x280<br /> [] device_add+0xae0/0x1cb0<br /> [] new_device_store+0x3b6/0x5f0<br /> [] bus_attr_store+0x72/0xa0<br /> [] sysfs_kf_write+0x106/0x160<br /> [] kernfs_fop_write_iter+0x3a8/0x5a0<br /> [] vfs_write+0x8f0/0xc80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: Fix double free in dvb_register_device()<br /> <br /> In function dvb_register_device() -&gt; dvb_register_media_device() -&gt;<br /> dvb_create_media_entity(), dvb-&gt;entity is allocated and initialized. If<br /> the initialization fails, it frees the dvb-&gt;entity, and return an error<br /> code. The caller takes the error code and handles the error by calling<br /> dvb_media_device_free(), which unregisters the entity and frees the<br /> field again if it is not NULL. As dvb-&gt;entity may not NULLed in<br /> dvb_create_media_entity() when the allocation of dvbdev-&gt;pad fails, a<br /> double free may occur. This may also cause an Use After free in<br /> media_device_unregister_entity().<br /> <br /> Fix this by storing NULL to dvb-&gt;entity when it is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate data run offset<br /> <br /> This adds sanity checks for data run offset. We should make sure data<br /> run offset is legit before trying to unpack them, otherwise we may<br /> encounter use-after-free or some unexpected memory access behaviors.<br /> <br /> [ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570<br /> [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240<br /> [ 82.941670]<br /> [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15<br /> [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 82.943720] Call Trace:<br /> [ 82.944204] <br /> [ 82.944471] dump_stack_lvl+0x49/0x63<br /> [ 82.944908] print_report.cold+0xf5/0x67b<br /> [ 82.945141] ? __wait_on_bit+0x106/0x120<br /> [ 82.945750] ? run_unpack+0x2e3/0x570<br /> [ 82.946626] kasan_report+0xa7/0x120<br /> [ 82.947046] ? run_unpack+0x2e3/0x570<br /> [ 82.947280] __asan_load1+0x51/0x60<br /> [ 82.947483] run_unpack+0x2e3/0x570<br /> [ 82.947709] ? memcpy+0x4e/0x70<br /> [ 82.947927] ? run_pack+0x7a0/0x7a0<br /> [ 82.948158] run_unpack_ex+0xad/0x3f0<br /> [ 82.948399] ? mi_enum_attr+0x14a/0x200<br /> [ 82.948717] ? run_unpack+0x570/0x570<br /> [ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0<br /> [ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0<br /> [ 82.949611] ? mi_read+0x262/0x2c0<br /> [ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180<br /> [ 82.950249] ntfs_iget5+0x632/0x1870<br /> [ 82.950621] ? ntfs_get_block_bmap+0x70/0x70<br /> [ 82.951192] ? evict+0x223/0x280<br /> [ 82.951525] ? iput.part.0+0x286/0x320<br /> [ 82.951969] ntfs_fill_super+0x1321/0x1e20<br /> [ 82.952436] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.952822] ? vsprintf+0x20/0x20<br /> [ 82.953188] ? mutex_unlock+0x81/0xd0<br /> [ 82.953379] ? set_blocksize+0x95/0x150<br /> [ 82.954001] get_tree_bdev+0x232/0x370<br /> [ 82.954438] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.954700] ntfs_fs_get_tree+0x15/0x20<br /> [ 82.955049] vfs_get_tree+0x4c/0x130<br /> [ 82.955292] path_mount+0x645/0xfd0<br /> [ 82.955615] ? putname+0x80/0xa0<br /> [ 82.955955] ? finish_automount+0x2e0/0x2e0<br /> [ 82.956310] ? kmem_cache_free+0x110/0x390<br /> [ 82.956723] ? putname+0x80/0xa0<br /> [ 82.957023] do_mount+0xd6/0xf0<br /> [ 82.957411] ? path_mount+0xfd0/0xfd0<br /> [ 82.957638] ? __kasan_check_write+0x14/0x20<br /> [ 82.957948] __x64_sys_mount+0xca/0x110<br /> [ 82.958310] do_syscall_64+0x3b/0x90<br /> [ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 82.959341] RIP: 0033:0x7fd0d1ce948a<br /> [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a<br /> [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0<br /> [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020<br /> [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0<br /> [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff