Red Hat

In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier",...

CVE-2022-50505 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2022-50504 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: mtd: lpddr2_nvm: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(add_range) invoked, if platform_get_resource() returns NULL.

In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for dcoda_iram_alloc As the coda_iram_alloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.

In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed If some items in nsim_dev_resources_register() fail, memory leak will occur. The following is the memory leak information. unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80

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

CVE-2022-50498 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: fix shift-out-of-bounds in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned long, we should define these macros with same type too.

In the Linux kernel, the following vulnerability has been resolved: dm cache: Fix UAF in destroy() Dm_cache also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in destroy().

In the Linux kernel, the following vulnerability has been resolved: thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG: BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ... Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning. Use get_cpu() instead of smp_processor_id() to avoid this BUG. [ rjw: Subject edits ]

In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix use-after-free on probe deferral The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral). Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted. Patchwork: https://patchwork.freedesktop.org/patch/502665/

CVE-2022-50491 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns -EBUSY, it will go to next bucket.

A remote code execution vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN:...

CVE-2022-50486 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode There are many places that will get unhappy (and crash) when ext4_iget() returns a bad inode.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential memory leaks When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.

CVE-2022-50483 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

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

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

CVE-2022-50480 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

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

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

In the Linux kernel, the following vulnerability has been resolved: rtc: class: Fix potential memleak in devm_rtc_allocate_device() devm_rtc_allocate_device() will alloc a rtc_device first, and then run dev_set_name(). If dev_set_name() failed, the rtc_device will memleak. Move devm_add_action_or_reset() in front of dev_set_name() to prevent memleak. unreferenced object 0xffff888110a53000 (size 2048): comm "python3", pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0...... 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0.............. backtrace: [<000000004aac0364>] kmalloc_trace+0x21/0x110 [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400 [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80 [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581] [<00000000f0eba0ae>] spi_probe+0xde/0x130 [<00000000bff89ee8>] really_probe+0x175/0x3f0 [<00000000128e8d84>] __driver_probe_device+0xe6/0x170 [<00000000ee5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store+0x49/0x70 [<000000008139c323>] sysfs_kf_write+0x8d/0xb0 [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0 [<00000000ecbe3895>] vfs_write+0x61a/0x7d0 [<00000000aa2196ea>] ksys_write+0xc8/0x190 [<0000000046a600f5>] do_syscall_64+0x37/0x90 [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Make sure "ib_port" is valid when access sysfs node The "ib_port" structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP 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] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)

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

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

CVE-2022-50472 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2022-50471 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.

In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.

In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ struct sockaddr_in sockaddr; struct tcp_ao_add tcp_ao; int sk; int one = 1; memset(&sockaddr,'\0',sizeof(sockaddr)); memset(&tcp_ao,'\0',sizeof(tcp_ao)); sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr.sin_family = AF_INET; memcpy(tcp_ao.alg_name,"cmac(aes128)",12); memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16); tcp_ao.keylen = 16; memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, sizeof(tcp_ao)); setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); sockaddr.sin_family = AF_INET; sockaddr.sin_port = htobe16(123); inet_aton("127.0.0.1", &sockaddr.sin_addr); connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)

CVE-2025-39949 is a security vulnerability (CVSS 5.5). Risk factors: public PoC available. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame.

In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays - such as inserting calls to ssleep() within the cnic_delete_task() function - to increase the likelihood of triggering the bug.

CVE-2025-39942 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.

In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;

In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Fix memory corruption when using identity domain zpci_get_iommu_ctrs() returns counter information to be reported as part of device statistics; these counters are...

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0

In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property")...

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked() When 9770b428b1a2

In the Linux kernel, the following vulnerability has been resolved: ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded() The sma1307->set.header_size is how many integers are in the header (there are 8 of them) but instead of...

In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.

CVE-2025-39933 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2025-39932 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In fetchmail before 6.5.6, the SMTP client can crash when authenticating upon receiving a 334 status code in a malformed context.

UAF in Redis 8.2.1 via crafted Lua scripts by authenticated users. EPSS 12.4%. Patch available.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted LUA script to read out-of-bound data or crash the server and subsequent denial of service. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user. The problem exists in all versions of Redis with LUA scripting. This issue is fixed in version 8.2.2. A workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing LUA scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2.

Use-after-free in SVG pattern parsing — pattern node deleted but accessed later.

Stack overflow DoS in SVG rendering via recursive pattern elements.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. For versions 2.9.0-rc1 through 2.14.19, 3.0.0-rc1 through 3.2.0-rc1, 3.1.6 and 3.0.17, when the webhook.azuredevops.username and webhook.azuredevops.password are not set in the default configuration, the /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty. The slice index [0] is accessed without a length check, causing an index-out-of-range panic. A single unauthenticated HTTP POST is enough to kill the process. This issue is resolved in versions 2.14.20, 3.2.0-rc2, 3.1.8 and 3.0.19.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions 1.2.0 through 1.8.7, 2.0.0-rc1 through 2.14.19, 3.0.0-rc1 through 3.2.0-rc1, 3.1.7 and 3.0.18 are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients. With the default configuration, no webhook.gogs.secret set, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Gogs push event whose JSON field commits[].repo is not set or is null. This issue is fixed in versions 2.14.20, 3.2.0-rc2, 3.1.8 and 3.0.19.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions 1.2.0 through 1.8.7, 2.0.0-rc1 through 2.14.19, 3.0.0-rc1 through 3.2.0-rc1, 3.1.7 and 3.0.18 are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients. Without a configured webhook.bitbucketserver.secret, Argo CD's /api/webhook endpoint crashes when receiving a malformed Bitbucket Server payload (non-array repository.links.clone field). A single unauthenticated request triggers CrashLoopBackOff, and targeting all replicas causes complete API outage. This issue is fixed in versions 2.14.20, 3.2.0-rc2, 3.1.8 and 3.0.19.

An issue was discovered in Django 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7. QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() are subject to SQL injection in column aliases, when using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods (on MySQL and MariaDB).

Starting from Rust 1.87.0 and before Rust 1.89.0, the tier 3 Cygwin target (`x86_64-pc-cygwin`) didn't correctly handle path separators, causing the standard library's Path API to ignore path components separated by backslashes. Due to this, programs compiled for Cygwin that validate paths could misbehave, potentially allowing path traversal attacks or malicious filesystem operations. Rust 1.89.0 fixes the issue by handling both Win32 and Unix style paths in the standard library for the Cygwin target. While we assess the severity of this vulnerability as "medium", please note that the tier 3 Cygwin compilation target is only available when building it from source: no pre-built binaries are distributed by the Rust project, and it cannot be installed through Rustup. Unless you manually compiled the `x86_64-pc-cygwin` target you are not affected by this vulnerability. Users of the tier 1 MinGW target (`x86_64-pc-windows-gnu`) are also explicitly not affected.

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix deinitialization of firmware resources Currently, in ath11k_ahb_fw_resources_init(), iommu domain mapping is done only for the chipsets having fixed...

In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/

CVE-2023-53530 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix memory leak in rtw88_usb Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit().

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request() The memory allocated in tb_queue_dp_bandwidth_request() needs to be released once the request is handled to avoid leaking it.

In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix leak in devfreq_dev_release() srcu_init_notifier_head() allocates resources that need to be released with a srcu_cleanup_notifier_head() call. Reported by kmemleak.

In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix memory leak of device names The device names allocated by dev_set_name() need be freed before module unloading, but they can not be freed because the kobject's refcount which was set in device_initialize() has not be decreased to 0. As comment of device_add() says, if it fails, use only put_device() drop the refcount, then the name will be freed in kobejct_cleanup(). device_del() and put_device() can be replaced with device_unregister(), so call it to unregister the added successfully devices, and just call put_device() to the not added device. Add a release() function to device to avoid null release() function WARNING in device_release(), it's empty, because the context devices are freed together in host1x_memory_context_list_free().

In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix a memory leak Add a forgotten kfree().

CVE-2023-53509 is a security vulnerability (CVSS 5.5) that allows sleep. Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2023-53508 is a security vulnerability (CVSS 7.8). High severity vulnerability requiring prompt remediation. Vendor patch is available.

CVE-2023-53507 is a security vulnerability (CVSS 7.8). High severity vulnerability requiring prompt remediation. Vendor patch is available.

CVE-2023-53506 is a security vulnerability (CVSS 7.8). High severity vulnerability requiring prompt remediation. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: clk: tegra: tegra124-emc: Fix potential memory leak The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked.

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF ib_dealloc_device() should be called only after device cleanup. Fix the dealloc sequence.

In the Linux kernel, the following vulnerability has been resolved: iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind When unbinding pasid - a race condition exists vs outstanding page faults. To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbind Since refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory") Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1.

In the Linux kernel, the following vulnerability has been resolved: xfrm: fix slab-use-after-free in decode_session6 When the xfrm device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when the xfrm device sends IPv6 packets. The stack information is as follows: BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890 Read of size 1 at addr ffff8881111458ef by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11d/0x130 decode_session6+0x103f/0x1890 __xfrm_decode_session+0x54/0xb0 xfrmi_xmit+0x173/0x1ca0 dev_hard_start_xmit+0x187/0x700 sch_direct_xmit+0x1a3/0xc30 __qdisc_run+0x510/0x17a0 __dev_queue_xmit+0x2215/0x3b10 neigh_connected_output+0x3c2/0x550 ip6_finish_output2+0x55a/0x1550 ip6_finish_output+0x6b9/0x1270 ip6_output+0x1f1/0x540 ndisc_send_skb+0xa63/0x1890 ndisc_send_rs+0x132/0x6f0 addrconf_rs_timer+0x3f1/0x870 call_timer_fn+0x1a0/0x580 expire_timers+0x29b/0x4b0 run_timer_softirq+0x326/0x910 __do_softirq+0x1d4/0x905 irq_exit_rcu+0xb7/0x120 sysvec_apic_timer_interrupt+0x97/0xc0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:intel_idle_hlt+0x23/0x30 Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 <fa> 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4 RSP: 0018:ffffc90000197d78 EFLAGS: 00000246 RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5 RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50 RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000 cpuidle_enter_state+0xd3/0x6f0 cpuidle_enter+0x4e/0xa0 do_idle+0x2fe/0x3c0 cpu_startup_entry+0x18/0x20 start_secondary+0x200/0x290 secondary_startup_64_no_verify+0x167/0x16b </TASK> Allocated by task 939: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_slab_alloc+0x7f/0x90 kmem_cache_alloc_node+0x1cd/0x410 kmalloc_reserve+0x165/0x270 __alloc_skb+0x129/0x330 inet6_ifa_notify+0x118/0x230 __ipv6_ifa_notify+0x177/0xbe0 addrconf_dad_completed+0x133/0xe00 addrconf_dad_work+0x764/0x1390 process_one_work+0xa32/0x16f0 worker_thread+0x67d/0x10c0 kthread+0x344/0x440 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888111145800 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 239 bytes inside of freed 640-byte region [ffff888111145800, ffff888111145a80) As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.

CVE-2023-53499 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null dereference The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini() without checking. Add a NULL pointer check before calling dc_dmub_srv_destroy(). Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved: media: vsp1: Replace vb2_is_streaming() with vb2_start_streaming_called() The vsp1 driver uses the vb2_is_streaming() function in its .buf_queue() handler to check if the .start_streaming() operation has been called, and decide whether to just add the buffer to an internal queue, or also trigger a hardware run. vb2_is_streaming() relies on the vb2_queue structure's streaming field, which used to be set only after calling the .start_streaming() operation. Commit a10b21532574 ("media: vb2: add (un)prepare_streaming queue ops") changed this, setting the .streaming field in vb2_core_streamon() before enqueuing buffers to the driver and calling .start_streaming(). This broke the vsp1 driver which now believes that .start_streaming() has been called when it hasn't, leading to a crash: [ 881.058705] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 881.067495] Mem abort info: [ 881.070290] ESR = 0x0000000096000006 [ 881.074042] EC = 0x25: DABT (current EL), IL = 32 bits [ 881.079358] SET = 0, FnV = 0 [ 881.082414] EA = 0, S1PTW = 0 [ 881.085558] FSC = 0x06: level 2 translation fault [ 881.090439] Data abort info: [ 881.093320] ISV = 0, ISS = 0x00000006 [ 881.097157] CM = 0, WnR = 0 [ 881.100126] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004fa51000 [ 881.106573] [0000000000000020] pgd=080000004f36e003, p4d=080000004f36e003, pud=080000004f7ec003, pmd=0000000000000000 [ 881.117217] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ 881.123494] Modules linked in: rcar_fdp1 v4l2_mem2mem [ 881.128572] CPU: 0 PID: 1271 Comm: yavta Tainted: G B 6.2.0-rc1-00023-g6c94e2e99343 #556 [ 881.138061] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 881.145981] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 881.152951] pc : vsp1_dl_list_add_body+0xa8/0xe0 [ 881.157580] lr : vsp1_dl_list_add_body+0x34/0xe0 [ 881.162206] sp : ffff80000c267710 [ 881.165522] x29: ffff80000c267710 x28: ffff000010938ae8 x27: ffff000013a8dd98 [ 881.172683] x26: ffff000010938098 x25: ffff000013a8dc00 x24: ffff000010ed6ba8 [ 881.179841] x23: ffff00000faa4000 x22: 0000000000000000 x21: 0000000000000020 [ 881.186998] x20: ffff00000faa4000 x19: 0000000000000000 x18: 0000000000000000 [ 881.194154] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 881.201309] x14: 0000000000000000 x13: 746e696174206c65 x12: ffff70000157043d [ 881.208465] x11: 1ffff0000157043c x10: ffff70000157043c x9 : dfff800000000000 [ 881.215622] x8 : ffff80000ab821e7 x7 : 00008ffffea8fbc4 x6 : 0000000000000001 [ 881.222779] x5 : ffff80000ab821e0 x4 : ffff70000157043d x3 : 0000000000000020 [ 881.229936] x2 : 0000000000000020 x1 : ffff00000e4f6400 x0 : 0000000000000000 [ 881.237092] Call trace: [ 881.239542] vsp1_dl_list_add_body+0xa8/0xe0 [ 881.243822] vsp1_video_pipeline_run+0x270/0x2a0 [ 881.248449] vsp1_video_buffer_queue+0x1c0/0x1d0 [ 881.253076] __enqueue_in_driver+0xbc/0x260 [ 881.257269] vb2_start_streaming+0x48/0x200 [ 881.261461] vb2_core_streamon+0x13c/0x280 [ 881.265565] vb2_streamon+0x3c/0x90 [ 881.269064] vsp1_video_streamon+0x2fc/0x3e0 [ 881.273344] v4l_streamon+0x50/0x70 [ 881.276844] __video_do_ioctl+0x2bc/0x5d0 [ 881.280861] video_usercopy+0x2a8/0xc80 [ 881.284704] video_ioctl2+0x20/0x40 [ 881.288201] v4l2_ioctl+0xa4/0xc0 [ 881.291525] __arm64_sys_ioctl+0xe8/0x110 [ 881.295543] invoke_syscall+0x68/0x190 [ 881.299303] el0_svc_common.constprop.0+0x88/0x170 [ 881.304105] do_el0_svc+0x4c/0xf0 [ 881.307430] el0_svc+0x4c/0xa0 [ 881.310494] el0t_64_sync_handler+0xbc/0x140 [ 881.314773] el0t_64_sync+0x190/0x194 [ 881.318450] Code: d50323bf d65f03c0 91008263 f9800071 (885f7c60) [ 881.324551] ---[ end trace 0000000000000000 ]--- [ 881.329173] note: yavta[1271] exited with preempt_count 1 A different r ---truncated---

A remote code execution vulnerability (CVSS 5.5) that allows it. Remediation should follow standard vulnerability management procedures. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc() rules is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rules to avoid OOB writing or NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved: crypto: xts - Handle EBUSY correctly As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved: accel/qaic: tighten bounds checking in decode_message() Copy the bounds checking from encode_message() to decode_message(). This patch addresses the following concerns. Ensure that there is enough space for at least one header so that we don't have a negative size later. if (msg_hdr_len < sizeof(*trans_hdr)) Ensure that we have enough space to read the next header from the msg->data. if (msg_len > msg_hdr_len - sizeof(*trans_hdr)) return -EINVAL; Check that the trans_hdr->len is not below the minimum size: if (hdr_len < sizeof(*trans_hdr)) This minimum check ensures that we don't corrupt memory in decode_passthrough() when we do. memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr)); And finally, use size_add() to prevent an integer overflow: if (size_add(msg_len, hdr_len) > msg_hdr_len)

CVE-2023-53492 is a security vulnerability (CVSS 7.8). High severity vulnerability requiring prompt remediation. Vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: start_kernel: Add __no_stack_protector function attribute Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it. Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix disconnect vs accept race Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in recvmsg()"), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept. The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock. As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat: BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them. After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal.

In the Linux kernel, the following vulnerability has been resolved: tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp. syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences: sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close() sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp. When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is not called. The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inet_sock_destruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb. TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skb_queue_purge() call. In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs(). [0]: BUG: memory leak unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---

CVE-2023-53488 is a security vulnerability (CVSS 5.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.