Vulnerabilities > NULL Pointer Dereference
| DATE | CVE | VULNERABILITY TITLE | RISK |
|---|---|---|---|
| 2024-09-18 | CVE-2024-46763 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: fou: Fix null-ptr-deref in GRO. We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. | 5.5 |
| 2024-09-18 | CVE-2024-46765 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ice: protect XDP configuration with a mutex The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. | 5.5 |
| 2024-09-18 | CVE-2024-46768 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: hwmon: (hp-wmi-sensors) Check if WMI event data exists The BIOS can choose to return no event data in response to a WMI event, so the ACPI object passed to the WMI notify handler can be NULL. Check for such a situation and ignore the event in such a case. | 5.5 |
| 2024-09-18 | CVE-2024-46769 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: spi: intel: Add check devm_kasprintf() returned value intel_spi_populate_chip() use devm_kasprintf() to set pdata->name. This can return a NULL pointer on failure but this returned value is not checked. | 5.5 |
| 2024-09-18 | CVE-2024-46770 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. | 5.5 |
| 2024-09-18 | CVE-2024-46776 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Run DC_LOG_DC after checking link->link_enc [WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before. This fixes 1 REVERSE_INULL issue reported by Coverity. | 5.5 |
| 2024-09-18 | CVE-2024-46778 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check UnboundedRequestEnabled's value CalculateSwathAndDETConfiguration_params_st's UnboundedRequestEnabled is a pointer (i.e. | 5.5 |
| 2024-09-18 | CVE-2024-46785 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: eventfs: Use list_del_rcu() for SRCU protected list variable Chi Zhiling reported: We found a null pointer accessing in tracefs[1], the reason is that the variable 'ei_child' is set to LIST_POISON1, that means the list was removed in eventfs_remove_rec. | 5.5 |
| 2024-09-18 | CVE-2024-46788 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Use a cpumask to know what threads are kthreads The start_kthread() and stop_thread() code was not always called with the interface_lock held. | 5.5 |
| 2024-09-18 | CVE-2024-46793 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards harder Since commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") dummy codecs declared like this: SND_SOC_DAILINK_DEF(dummy, DAILINK_COMP_ARRAY(COMP_DUMMY())); expand to: static struct snd_soc_dai_link_component dummy[] = { }; Which means that dummy is a zero sized array and thus dais[i].codecs should not be dereferenced *at all* since it points to the address of the next variable stored in the data section as the "dummy" variable has an address but no size, so even dereferencing dais[0] is already an out of bounds array reference. Which means that the if (dais[i].codecs->name) check added in commit 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") relies on that the part of the next variable which the name member maps to just happens to be NULL. Which apparently so far it usually is, except when it isn't and then it results in crashes like this one: [ 28.795659] BUG: unable to handle page fault for address: 0000000000030011 ... [ 28.795780] Call Trace: [ 28.795787] <TASK> ... [ 28.795862] ? strcmp+0x18/0x40 [ 28.795872] 0xffffffffc150c605 [ 28.795887] platform_probe+0x40/0xa0 ... [ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102] Really fix things this time around by checking dais.num_codecs != 0. | 5.5 |