Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Propagate error from htab_lock_bucket() to userspace<br /> <br /> In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns<br /> -EBUSY, it will go to next bucket. Going to next bucket may not only<br /> skip the elements in current bucket silently, but also incur<br /> out-of-bound memory access or expose kernel memory to userspace if<br /> current bucket_cnt is greater than bucket_size or zero.<br /> <br /> Fixing it by stopping batch operation and returning -EBUSY when<br /> htab_lock_bucket() fails, and the application can retry or skip the busy<br /> batch as needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: class: Fix potential memleak in devm_rtc_allocate_device()<br /> <br /> devm_rtc_allocate_device() will alloc a rtc_device first, and then run<br /> dev_set_name(). If dev_set_name() failed, the rtc_device will memleak.<br /> Move devm_add_action_or_reset() in front of dev_set_name() to prevent<br /> memleak.<br /> <br /> unreferenced object 0xffff888110a53000 (size 2048):<br /> comm "python3", pid 470, jiffies 4296078308 (age 58.882s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0......<br /> 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............<br /> backtrace:<br /> [] kmalloc_trace+0x21/0x110<br /> [] devm_rtc_allocate_device+0xd4/0x400<br /> [] devm_rtc_device_register+0x1a/0x80<br /> [] rx4581_probe+0xdd/0x110 [rtc_rx4581]<br /> [] spi_probe+0xde/0x130<br /> [] really_probe+0x175/0x3f0<br /> [] __driver_probe_device+0xe6/0x170<br /> [] device_driver_attach+0x32/0x80<br /> [] bind_store+0x10b/0x1a0<br /> [] drv_attr_store+0x49/0x70<br /> [] sysfs_kf_write+0x8d/0xb0<br /> [] kernfs_fop_write_iter+0x214/0x2d0<br /> [] vfs_write+0x61a/0x7d0<br /> [] ksys_write+0xc8/0x190<br /> [] do_syscall_64+0x37/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb_netdev: Use dev_kfree_skb_any() in interrupt context<br /> <br /> TX/RX callback handlers (ntb_netdev_tx_handler(),<br /> ntb_netdev_rx_handler()) can be called in interrupt<br /> context via the DMA framework when the respective<br /> DMA operations have completed. As such, any calls<br /> by these routines to free skb&amp;#39;s, should use the<br /> interrupt context safe dev_kfree_skb_any() function.<br /> <br /> Previously, these callback handlers would call the<br /> interrupt unsafe version of dev_kfree_skb(). This has<br /> not presented an issue on Intel IOAT DMA engines as<br /> that driver utilizes tasklets rather than a hard<br /> interrupt handler, like the AMD PTDMA DMA driver.<br /> On AMD systems, a kernel WARNING message is<br /> encountered, which is being issued from<br /> skb_release_head_state() due to in_hardirq()<br /> being true.<br /> <br /> Besides the user visible WARNING from the kernel,<br /> the other symptom of this bug was that TCP/IP performance<br /> across the ntb_netdev interface was very poor, i.e.<br /> approximately an order of magnitude below what was<br /> expected. With the repair to use dev_kfree_skb_any(),<br /> kernel WARNINGs from skb_release_head_state() ceased<br /> and TCP/IP performance, as measured by iperf, was on<br /> par with expected results, approximately 20 Gb/s on<br /> AMD Milan based server. Note that this performance<br /> is comparable with Intel based servers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Make sure "ib_port" is valid when access sysfs node<br /> <br /> The "ib_port" structure must be set before adding the sysfs kobject,<br /> and reset after removing it, otherwise it may crash when accessing<br /> the sysfs node:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050<br /> Mem abort info:<br /> ESR = 0x96000006<br /> Exception class = DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5<br /> [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#2] PREEMPT SMP<br /> Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci]<br /> Process grep (pid: 3372, stack limit = 0x0000000022055c92)<br /> CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1<br /> Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022<br /> pstate: 40000005 (nZcv daif -PAN -UAO)<br /> pc : hw_stat_port_show+0x4c/0x80 [ib_core]<br /> lr : port_attr_show+0x40/0x58 [ib_core]<br /> sp : ffff000029f43b50<br /> x29: ffff000029f43b50 x28: 0000000019375000<br /> x27: ffff8007b821a540 x26: ffff000029f43e30<br /> x25: 0000000000008000 x24: ffff000000eaa958<br /> x23: 0000000000001000 x22: ffff8007a4ce3000<br /> x21: ffff8007baff8000 x20: ffff8007b9066ac0<br /> x19: ffff8007bae97578 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000<br /> x15: 0000000000000000 x14: 0000000000000000<br /> x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000<br /> x9 : 0000000000000000 x8 : ffff8007a4ce4000<br /> x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : ffff000000e6a280 x4 : ffff8007a4ce3000<br /> x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab<br /> x1 : ffff8007b9066a10 x0 : ffff8007baff8000<br /> Call trace:<br /> hw_stat_port_show+0x4c/0x80 [ib_core]<br /> port_attr_show+0x40/0x58 [ib_core]<br /> sysfs_kf_seq_show+0x8c/0x150<br /> kernfs_seq_show+0x44/0x50<br /> seq_read+0x1b4/0x45c<br /> kernfs_fop_read+0x148/0x1d8<br /> __vfs_read+0x58/0x180<br /> vfs_read+0x94/0x154<br /> ksys_read+0x68/0xd8<br /> __arm64_sys_read+0x28/0x34<br /> el0_svc_common+0x88/0x18c<br /> el0_svc_handler+0x78/0x94<br /> el0_svc+0x8/0xe8<br /> Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: fix potential memory leak<br /> <br /> This patch fix potential memory leak (clk_src) when function run<br /> into last return NULL.<br /> <br /> s/free/kfree/ - Alex

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()<br /> <br /> Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount<br /> time".<br /> <br /> The first patch fixes a bug reported by syzbot, and the second one fixes<br /> the remaining bug of the same kind. Although they are triggered by the<br /> same super block data anomaly, I divided it into the above two because the<br /> details of the issues and how to fix it are different.<br /> <br /> Both are required to eliminate the shift-out-of-bounds issues at mount<br /> time.<br /> <br /> <br /> This patch (of 2):<br /> <br /> If the block size exponent information written in an on-disk superblock is<br /> corrupted, nilfs_sb2_bad_offset helper function can trigger<br /> shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn<br /> is set):<br /> <br /> shift exponent 38983 is too large for 64-bit type &amp;#39;unsigned long long&amp;#39;<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:151 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322<br /> nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]<br /> nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523<br /> init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577<br /> nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047<br /> nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317<br /> ...<br /> <br /> In addition, since nilfs_sb2_bad_offset() performs multiplication without<br /> considering the upper bound, the computation may overflow if the disk<br /> layout parameters are not normal.<br /> <br /> This fixes these issues by inserting preliminary sanity checks for those<br /> parameters and by converting the comparison from one involving<br /> multiplication and left bit-shifting to one using division and right<br /> bit-shifting.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()<br /> <br /> The break of for_each_available_child_of_node() needs a<br /> corresponding of_node_put() when the reference &amp;#39;child&amp;#39; is not<br /> used anymore. Here we do not need to call of_node_put() in<br /> fail path as &amp;#39;!match&amp;#39; means no break.<br /> <br /> While the of_platform_device_create() will created a new<br /> reference by &amp;#39;child&amp;#39; but it has considered the refcounting.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()<br /> <br /> If device_register() fails in cxl_register_afu|adapter(), the device<br /> is not added, device_unregister() can not be called in the error path,<br /> otherwise it will cause a null-ptr-deref because of removing not added<br /> device.<br /> <br /> As comment of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So split device_unregister() into<br /> device_del() and put_device(), then goes to put dev when register fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Clean up si_domain in the init_dmars() error path<br /> <br /> A splat from kmem_cache_destroy() was seen with a kernel prior to<br /> commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")<br /> when there was a failure in init_dmars(), because the iommu_domain<br /> cache still had objects. While the mempool code is now gone, there<br /> still is a leak of the si_domain memory if init_dmars() fails. So<br /> clean up si_domain in the init_dmars() error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh: fix possible memory leak in macio_add_one_device()<br /> <br /> Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically. It<br /> needs to be freed when of_device_register() fails. Call put_device() to<br /> give up the reference that&amp;#39;s taken in device_initialize(), so that it<br /> can be freed in kobject_cleanup() when the refcount hits 0.<br /> <br /> macio device is freed in macio_release_dev(), so the kfree() can be<br /> removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: Init completion before kobject_init_and_add()<br /> <br /> In cpufreq_policy_alloc(), it will call uninitialed completion in<br /> cpufreq_sysfs_release() when kobject_init_and_add() fails. And<br /> that will cause a crash such as the following page fault in complete:<br /> <br /> BUG: unable to handle page fault for address: fffffffffffffff8<br /> [..]<br /> RIP: 0010:complete+0x98/0x1f0<br /> [..]<br /> Call Trace:<br /> kobject_put+0x1be/0x4c0<br /> cpufreq_online.cold+0xee/0x1fd<br /> cpufreq_add_dev+0x183/0x1e0<br /> subsys_interface_register+0x3f5/0x4e0<br /> cpufreq_register_driver+0x3b7/0x670<br /> acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq]<br /> do_one_initcall+0x13d/0x780<br /> do_init_module+0x1c3/0x630<br /> load_module+0x6e67/0x73b0<br /> __do_sys_finit_module+0x181/0x240<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mad: Don&amp;#39;t call to function that might sleep while in atomic context<br /> <br /> Tracepoints are not allowed to sleep, as such the following splat is<br /> generated due to call to ib_query_pkey() in atomic context.<br /> <br /> WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220<br /> CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014<br /> Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]<br /> RIP: 0010:rb_commit+0xc1/0x220<br /> RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202<br /> RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246<br /> RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246<br /> R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x1d/0xa0<br /> trace_buffer_unlock_commit_regs+0x3b/0x1b0<br /> trace_event_buffer_commit+0x67/0x1d0<br /> trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]<br /> ib_mad_recv_done+0x48b/0xc10 [ib_core]<br /> ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]<br /> __ib_process_cq+0x91/0x1c0 [ib_core]<br /> ib_cq_poll_work+0x26/0x80 [ib_core]<br /> process_one_work+0x1a7/0x360<br /> ? create_worker+0x1a0/0x1a0<br /> worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x116/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x35/0x40<br /> ---[ end trace 78ba8509d3830a16 ]---