Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko<br /> <br /> If the driver support subdev mode, the parameter "dev-&gt;pm.dev" will be<br /> NULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmod<br /> mtk-vcodec-dec.ko.<br /> <br /> [ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80<br /> [ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c<br /> [ 4380.711509] sp : ffff80000819bc10<br /> [ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000<br /> [ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> [ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220<br /> [ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020<br /> [ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976<br /> [ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040<br /> [ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> [ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc<br /> [ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> [ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208<br /> [ 4380.786031] Call trace:<br /> [ 4380.788465] do_raw_spin_trylock+0x4/0x80<br /> [ 4380.792462] __pm_runtime_disable+0x2c/0x1b0<br /> [ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec]<br /> [ 4380.802466] platform_remove+0x2c/0x60<br /> [ 4380.806204] __device_release_driver+0x194/0x250<br /> [ 4380.810810] driver_detach+0xc8/0x15c<br /> [ 4380.814462] bus_remove_driver+0x5c/0xb0<br /> [ 4380.818375] driver_unregister+0x34/0x64<br /> [ 4380.822288] platform_driver_unregister+0x18/0x24<br /> [ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec]<br /> [ 4380.833240] __arm64_sys_delete_module+0x190/0x224<br /> [ 4380.838020] invoke_syscall+0x48/0x114<br /> [ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c<br /> [ 4380.846540] do_el0_svc+0x28/0x90<br /> [ 4380.849844] el0_svc+0x4c/0x100<br /> [ 4380.852975] el0t_64_sync_handler+0xec/0xf0<br /> [ 4380.857148] el0t_64_sync+0x190/0x194<br /> [ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: remove two BUG() from skb_checksum_help()<br /> <br /> I have a syzbot report that managed to get a crash in skb_checksum_help()<br /> <br /> If syzbot can trigger these BUG(), it makes sense to replace<br /> them with more friendly WARN_ON_ONCE() since skb_checksum_help()<br /> can instead return an error code.<br /> <br /> Note that syzbot will still crash there, until real bug is fixed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Check for null pointer of pointer substream before dereferencing it<br /> <br /> Pointer substream is being dereferenced on the assignment of pointer card<br /> before substream is being null checked with the macro PCM_RUNTIME_CHECK.<br /> Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the<br /> the pointer check before card is assigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init<br /> <br /> Syzbot reported that -1 is used as array index. The problem was in<br /> missing validation check.<br /> <br /> hdw-&gt;unit_number is initialized with -1 and then if init table walk fails<br /> this value remains unchanged. Since code blindly uses this member for<br /> array indexing adding sanity check is the easiest fix for that.<br /> <br /> hdw-&gt;workpoll initialization moved upper to prevent warning in<br /> __flush_work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe<br /> <br /> of_find_device_by_node() takes reference, we should use put_device()<br /> to release it. when devm_kzalloc() fails, it doesn&amp;#39;t have a<br /> put_device(), it will cause refcount leak.<br /> Add missing put_device() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt<br /> <br /> of_node_get() returns a node with refcount incremented.<br /> Calling of_node_put() to drop the reference when not needed anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit<br /> <br /> If edp modeset init is failed due to panel being not ready and<br /> probe defers during drm bind, avoid clearing irqs and dereference<br /> hw_intr when hw_intr is null.<br /> <br /> BUG: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> <br /> Call trace:<br /> dpu_core_irq_uninstall+0x50/0xb0<br /> dpu_irq_uninstall+0x18/0x24<br /> msm_drm_uninit+0xd8/0x16c<br /> msm_drm_bind+0x580/0x5fc<br /> try_to_bring_up_master+0x168/0x1c0<br /> __component_add+0xb4/0x178<br /> component_add+0x1c/0x28<br /> dp_display_probe+0x38c/0x400<br /> platform_probe+0xb0/0xd0<br /> really_probe+0xcc/0x2c8<br /> __driver_probe_device+0xbc/0xe8<br /> driver_probe_device+0x48/0xf0<br /> __device_attach_driver+0xa0/0xc8<br /> bus_for_each_drv+0x8c/0xd8<br /> __device_attach+0xc4/0x150<br /> device_initial_probe+0x1c/0x28<br /> <br /> Changes in V2:<br /> - Update commit message and coreect fixes tag.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/484430/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector<br /> <br /> Fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector<br /> routine if the chip does not support dbdc and the hw reports band_idx<br /> set to 1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix null pointer dereference of pointer perfmon<br /> <br /> In the unlikely event that pointer perfmon is null the WARN_ON return path<br /> occurs after the pointer has already been deferenced. Fix this by only<br /> dereferencing perfmon after it has been null checked.