NULL Pointer Dereference

A NULL pointer dereference vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.1 ( 2025/07/09 ) and laterShow less

A NULL pointer dereference vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.1 ( 2025/07/09 ) and laterShow less

Volto is a ReactJS-based frontend for the Plone Content Management System. Versions 16.34.0 and below, 17.0.0 through 17.22.1, 18.0.0 through 18.27.1, and 19.0.0-alpha.1 through 19.0.0-alpha.5, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. This issue is fixed in versions 16.34.1, 17.22.2, 18.27.2 and 19.0.0-alpha.6.Show less

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.Show less

Suricata is a network IDS, IPS and NSM engine developed by the OISF (Open Information Security Foundation) and the Suricata community. Version 8.0.0's usage of the tls.subjectaltname keyword can lead to a segmentation fault when the decoded subjectaltname contains a NULL byte. This issue is fixed in version 8.0.1. To workaround this issue, disable rules using the tls.subjectaltname keyword.Show less

Suricata is a network IDS, IPS and NSM engine developed by the OISF (Open Information Security Foundation) and the Suricata community. Versions 8.0.0 and below incorrectly handle the entropy keyword when not anchored to a "sticky" buffer, which can lead to a segmentation fault. This issue is fixed in version 8.0.1. To workaround this issue, users can disable rules using the entropy keyword, or validate they are anchored to a sticky buffer.Show less

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/Show less

In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: fix time stamp counter initialization If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback. In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host. At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early. Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem. For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference. Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB.Show less

In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k.Show less

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.Show less

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---Show less

In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup() devm_kzalloc() may fail, clk_data->name might be NULL and will cause a NULL pointer dereference later. [ rjw: Subject and changelog edits ]Show less

In the Linux kernel, the following vulnerability has been resolved: kobject: Add sanity check for kset->kobj.ktype in kset_register() When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset); A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... Because I didn't initialize my_kset.kobj.ktype. According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype. So add sanity check to make sure kset->kobj.ktype is not NULL.Show less

In the Linux kernel, the following vulnerability has been resolved: iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry() This condition needs to match the previous "if (epcp->state == LISTEN) {" exactly to avoid a NULL dereference of either "listen_ep" or "ep". The problem is that "epcp" has been re-assigned so just testing "if (epcp->state == LISTEN) {" a second time is not sufficient.Show less

In the Linux kernel, the following vulnerability has been resolved: pwm: lpc32xx: Remove handling of PWM channels Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called.Show less

In the Linux kernel, the following vulnerability has been resolved: ionic: catch failure from devlink_alloc Add a check for NULL on the alloc return. If devlink_alloc() fails and we try to use devlink_priv() on the NULL return, the kernel gets very unhappy and panics. With this fix, the driver load will still fail, but at least it won't panic the kernel.Show less

In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en. Fix the issue by moving the position of the assignment.Show less

In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish() When the driver calls cx23885_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer risc->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of cx23885_risc_buffer() and the value of risc->cpu before buffer free.Show less

In the Linux kernel, the following vulnerability has been resolved: FS: JFS: Fix null-ptr-deref Read in txBegin Syzkaller reported an issue where txBegin may be called on a superblock in a read-only mounted filesystem which leads to NULL pointer deref. This could be solved by checking if the filesystem is read-only before calling txBegin, and returning with appropiate error code.Show less

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix potential NULL pointer dereference Klocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validate pointer before dereferencing the pointer.Show less