In the Linux kernel, the following vulnerability has been resolved: i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances vchiq_get_state() can return a NULL pointer. So handle this cases and avoid a NULL pointer derefence in vchiq_dump_platform_instances.

The xfs_dinode_verify function in fs/xfs/libxfs/xfs_inode_buf.c in the Linux kernel through 4.16.3 allows local users to cause a denial of service (xfs_ilock_attr_map_shared invalid pointer dereference) via a crafted xfs image.

The Linux Kernel versions 4.14, 4.15, and 4.16 has a null pointer dereference which can result in an out of memory (OOM) killing of large mlocked processes. The issue arises from an oom killed process's final thread calling exit_mmap(), which calls munlock_vma_pages_all() for mlocked vmas.This can happen synchronously with the oom reaper's unmap_page_range() since the vma's VM_LOCKED bit is cleared before munlocking (to determine if any other vmas share the memory and are mlocked).

In the Linux kernel, the following vulnerability has been resolved: phy: usb: sunplus: Fix potential null-ptr-deref in sp_usb_phy_probe() sp_usb_phy_probe() will call platform_get_resource_byname() that may fail and return NULL. devm_ioremap() will use usbphy->moon4_res_mem->start as input, which may causes null-ptr-deref. Check the ret value of platform_get_resource_byname() to avoid the null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.

Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code.

In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type.

In the Linux kernel, the following vulnerability has been resolved: hwrng: cavium - fix NULL but dereferenced coccicheck error Fix following coccicheck warning: ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR: pdev is NULL but dereferenced.

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link When using a fixed-link, the altr_tse_pcs driver crashes due to null-pointer dereference as no phy_device is provided to tse_pcs_fix_mac_speed function. Fix this by adding a check for phy_dev before calling the tse_pcs_fix_mac_speed() function. Also clean up the tse_pcs_fix_mac_speed function a bit. There is no need to check for splitter_base and sgmii_adapter_base because the driver will fail if these 2 variables are not derived from the device tree.

kernel/trace/trace_syscalls.c in the Linux kernel through 3.17.2 does not properly handle private syscall numbers during use of the ftrace subsystem, which allows local users to gain privileges or cause a denial of service (invalid pointer dereference) via a crafted application.

In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary.

In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.

In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.

In the Linux kernel, the following vulnerability has been resolved: soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code.

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix null pointer dereferences without iommu Check if 'aspace' is set before using it as it will stay null without IOMMU, such as on msm8974.

In the Linux kernel, the following vulnerability has been resolved: tipc: move bc link creation back to tipc_node_create Shuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] <IRQ> [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc] It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it creates a node in tipc_node_check_dest(), after inserting the new node into hashtable in tipc_node_create(), it creates the bc link. However, there is a gap between this insert and bc link creation, a bc packet may come in and get the node from the hashtable then try to dereference its bc link, which is NULL. This patch is to fix it by moving the bc link creation before inserting into the hashtable. Note that for a preliminary node becoming "real", the bc link creation should also be called before it's rehashed, as we don't create it for preliminary nodes.

In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add().

In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix NULL pointer dereference in dsa_port_reset_vlan_filtering The "ds" iterator variable used in dsa_port_reset_vlan_filtering() -> dsa_switch_for_each_port() overwrites the "dp" received as argument, which is later used to call dsa_port_vlan_filtering() proper. As a result, switches which do enter that code path (the ones with vlan_filtering_is_global=true) will dereference an invalid dp in dsa_port_reset_vlan_filtering() after leaving a VLAN-aware bridge. Use a dedicated "other_dp" iterator variable to avoid this from happening.

In the Linux kernel, the following vulnerability has been resolved: tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Fix this by checking whether the 'info->netdev' is a null pointer first.

In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Store vhost pointer during subcrq allocation Currently the back pointer from a queue to the vhost adapter isn't set until after subcrq interrupt registration. The value is available when a queue is first allocated and can/should be also set for primary and async queues as well as subcrqs. This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS interrupt controller where a pending subcrq interrupt from the previous kernel can be replayed immediately upon IRQ registration resulting in dereference of a garbage backpointer in ibmvfc_interrupt_scsi(). Kernel attempted to read user page (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit() When device is running and the interface status is changed, the gpf issue is triggered. The problem triggering process is as follows: Thread A: Thread B ieee80211_runtime_change_iftype() process_one_work() ... ... ieee80211_do_stop() ... ... ... sdata->bss = NULL ... ... ieee80211_subif_start_xmit() ieee80211_multicast_to_unicast //!sdata->bss->multicast_to_unicast cause gpf issue When the interface status is changed, the sending queue continues to send packets. After the bss is set to NULL, the bss is accessed. As a result, this causes a general-protection-fault issue. The following is the stack information: general protection fault, probably for non-canonical address 0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f] Workqueue: mld mld_ifc_work RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310 Call Trace: <TASK> dev_hard_start_xmit+0x1be/0x990 __dev_queue_xmit+0x2c9a/0x3b60 ip6_finish_output2+0xf92/0x1520 ip6_finish_output+0x6af/0x11e0 ip6_output+0x1ed/0x540 mld_sendpack+0xa09/0xe70 mld_ifc_work+0x71c/0xdb0 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK>

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing.

The sctp_assoc_update function in net/sctp/associola.c in the Linux kernel through 3.15.8, when SCTP authentication is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and OOPS) by starting to establish an association between two endpoints immediately after an exchange of INIT and INIT ACK chunks to establish an earlier association between these endpoints in the opposite direction.

NVIDIA GPU Display Driver contains a vulnerability in the kernel mode layer handler where a NULL pointer dereference may lead to denial of service or potential escalation of privileges

The ipv4_pktinfo_prepare function in net/ipv4/ip_sockglue.c in the Linux kernel through 4.9.9 allows attackers to cause a denial of service (system crash) via (1) an application that makes crafted system calls or possibly (2) IPv4 traffic with invalid IP options.

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_core: handle NULL result of find_service_by_handle In case of an invalid handle the function find_servive_by_handle returns NULL. So take care of this and avoid a NULL pointer dereference.

The rds_iw_laddr_check function in net/rds/iw.c in the Linux kernel through 3.14 allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact via a bind system call for an RDS socket on a system that lacks RDS transports.

In the Linux kernel, the following vulnerability has been resolved: ath11k: disable spectral scan during spectral deinit When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash. Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectral_deinit API to avoid this crash. call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)

In the Linux kernel, the following vulnerability has been resolved: ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue.

The Linux kernel before version 5.8 is vulnerable to a NULL pointer dereference in drivers/tty/serial/8250/8250_core.c:serial8250_isa_init_ports() that allows local users to cause a denial of service by using the p->serial_in pointer which uninitialized.

In the Linux kernel, the following vulnerability has been resolved: ice: always check VF VSI pointer values The ice_get_vf_vsi function can return NULL in some cases, such as if handling messages during a reset where the VSI is being removed and recreated. Several places throughout the driver do not bother to check whether this VSI pointer is valid. Static analysis tools maybe report issues because they detect paths where a potentially NULL pointer could be dereferenced. Fix this by checking the return value of ice_get_vf_vsi everywhere.

A NULL pointer dereference flaw was found in vmxnet3_rq_cleanup in drivers/net/vmxnet3/vmxnet3_drv.c in the networking sub-component in vmxnet3 in the Linux Kernel. This issue may allow a local attacker with normal user privilege to cause a denial of service due to a missing sanity check during cleanup.

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Guard against invalid local ports When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places.

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix NULL pointer problem in free_mr_init() Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutex_init() first before use the lock. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0

In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix decoder allocation crash When an intermediate port's decoders have been exhausted by existing regions, and creating a new region with the port in question in it's hierarchical path is attempted, cxl_port_attach_region() fails to find a port decoder (as would be expected), and drops into the failure / cleanup path. However, during cleanup of the region reference, a sanity check attempts to dereference the decoder, which in the above case didn't exist. This causes a NULL pointer dereference BUG. To fix this, refactor the decoder allocation and de-allocation into helper routines, and in this 'free' routine, check that the decoder, @cxld, is valid before attempting any operations on it.

The sctp_sf_do_5_1D_ce function in net/sctp/sm_statefuns.c in the Linux kernel through 3.13.6 does not validate certain auth_enable and auth_capable fields before making an sctp_sf_authenticate call, which allows remote attackers to cause a denial of service (NULL pointer dereference and system crash) via an SCTP handshake with a modified INIT chunk and a crafted AUTH chunk before a COOKIE_ECHO chunk.

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference

In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name().

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: populate connector of struct dp_panel DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose and expect DP source return correct checksum. During drm edid read, correct edid checksum is calculated and stored at connector::real_edid_checksum. The problem is struct dp_panel::connector never be assigned, instead the connector is stored in struct msm_dp::connector. When we run compliance testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set in struct dp_panel::edid so we'll try to use the connectors real_edid_checksum and hit a NULL pointer dereference error because the connector pointer is never assigned. Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Changes in V3: -- remove unhelpful kernel crash trace commit text -- remove renaming dp_display parameter to dp Changes in V4: -- add more details to commit text Changes in v10: -- group into one series Changes in v11: -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read Signee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>

In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/

The rds_ib_laddr_check function in net/rds/ib.c in the Linux kernel before 3.12.8 allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact via a bind system call for an RDS socket on a system that lacks RDS transports.

In the Linux kernel, the following vulnerability has been resolved: pinctrl: ralink: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix null-pointer dereference on edid reading Use i2c adapter when there isn't aux_mode in dc_link to fix a null-pointer derefence that happens when running igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector detected as below: [ +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0 [ +0.000010] #PF: supervisor read access in kernel mode [ +0.000005] #PF: error_code(0x0000) - not-present page [ +0.000004] PGD 0 P4D 0 [ +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152 [ +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021 [ +0.000004] RIP: 0010:i2c_transfer+0xd/0x100 [ +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16 [ +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246 [ +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080 [ +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0 [ +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980 [ +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080 [ +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f [ +0.000004] FS: 00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0 [ +0.000003] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000006] <TASK> [ +0.000006] ? __die+0x23/0x70 [ +0.000011] ? page_fault_oops+0x17d/0x4c0 [ +0.000008] ? preempt_count_add+0x6e/0xa0 [ +0.000008] ? srso_alias_return_thunk+0x5/0x7f [ +0.000011] ? exc_page_fault+0x7f/0x180 [ +0.000009] ? asm_exc_page_fault+0x26/0x30 [ +0.000013] ? i2c_transfer+0xd/0x100 [ +0.000010] drm_do_probe_ddc_edid+0xc2/0x140 [drm] [ +0.000067] ? srso_alias_return_thunk+0x5/0x7f [ +0.000006] ? _drm_do_get_edid+0x97/0x3c0 [drm] [ +0.000043] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000042] edid_block_read+0x3b/0xd0 [drm] [ +0.000043] _drm_do_get_edid+0xb6/0x3c0 [drm] [ +0.000041] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000043] drm_edid_read_custom+0x37/0xd0 [drm] [ +0.000044] amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu] [ +0.000153] drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper] [ +0.000000] __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper] [ +0.000000] ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu] [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper] [ +0.000000] status_store+0xb2/0x1f0 [drm] [ +0.000000] kernfs_fop_write_iter+0x136/0x1d0 [ +0.000000] vfs_write+0x24d/0x440 [ +0.000000] ksys_write+0x6f/0xf0 [ +0.000000] do_syscall_64+0x60/0xc0 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? syscall_exit_to_user_mode+0x2b/0x40 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ +0.000000] RIP: 0033:0x7f9ad46b4b00 [ +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 [ +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00 [ +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009 [ +0.000000] RBP: 0000000000000002 R08 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: KVM: Don't null dereference ops->destroy A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=NULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then.

In the Linux kernel, the following vulnerability has been resolved: XArray: Fix xas_create_range() when multi-order entry present If there is already an entry present that is of order >= XA_CHUNK_SHIFT when we call xas_create_range(), xas_create_range() will misinterpret that entry as a node and dereference xa_node->parent, generally leading to a crash that looks something like this: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 It's deterministically reproducable once you know what the problem is, but producing it in a live kernel requires khugepaged to hit a race. While the problem has been present since xas_create_range() was introduced, I'm not aware of a way to hit it before the page cache was converted to use multi-index entries.