Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()<br /> <br /> It will cause null-ptr-deref in resource_size(), if platform_get_resource()<br /> returns NULL, move calling resource_size() after devm_ioremap_resource() that<br /> will check &amp;#39;res&amp;#39; to avoid null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags<br /> <br /> In nvme_alloc_admin_tags, the admin_q can be set to an error (typically<br /> -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which<br /> is checked immediately after the call. However, when we return the error<br /> message up the stack, to nvme_reset_work the error takes us to<br /> nvme_remove_dead_ctrl()<br /> nvme_dev_disable()<br /> nvme_suspend_queue(&amp;dev-&gt;queues[0]).<br /> <br /> Here, we only check that the admin_q is non-NULL, rather than not<br /> an error or NULL, and begin quiescing a queue that never existed, leading<br /> to bad / NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: rt5645: Fix errorenous cleanup order<br /> <br /> There is a logic error when removing rt5645 device as the function<br /> rt5645_i2c_remove() first cancel the &amp;rt5645-&gt;jack_detect_work and<br /> delete the &amp;rt5645-&gt;btn_check_timer latter. However, since the timer<br /> handler rt5645_btn_check_callback() will re-queue the jack_detect_work,<br /> this cleanup order is buggy.<br /> <br /> That is, once the del_timer_sync in rt5645_i2c_remove is concurrently<br /> run with the rt5645_btn_check_callback, the canceled jack_detect_work<br /> will be rescheduled again, leading to possible use-after-free.<br /> <br /> This patch fix the issue by placing the del_timer_sync function before<br /> the cancel_delayed_work_sync.

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 /> mt76: fix tx status related use-after-free race on station removal<br /> <br /> There is a small race window where ongoing tx activity can lead to a skb<br /> getting added to the status tracking idr after that idr has already been<br /> cleaned up, which will keep the wcid linked in the status poll list.<br /> Fix this by only adding status skbs if the wcid pointer is still assigned<br /> in dev-&gt;wcid, which gets cleared early by mt76_sta_pre_rcu_remove

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.