Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: add RCU protection to mld_newpack()<br /> <br /> mld_newpack() can be called without RTNL or RCU being held.<br /> <br /> Note that we no longer can use sock_alloc_send_skb() because<br /> ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.<br /> <br /> Instead use alloc_skb() and charge the net-&gt;ipv6.igmp_sk<br /> socket under RCU protection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: extend RCU protection in igmp6_send()<br /> <br /> igmp6_send() can be called without RTNL or RCU being held.<br /> <br /> Extend RCU protection so that we can safely fetch the net pointer<br /> and avoid a potential UAF.<br /> <br /> Note that we no longer can use sock_alloc_send_skb() because<br /> ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.<br /> <br /> Instead use alloc_skb() and charge the net-&gt;ipv6.igmp_sk<br /> socket under RCU protection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ndisc: extend RCU protection in ndisc_send_skb()<br /> <br /> ndisc_send_skb() can be called without RTNL or RCU held.<br /> <br /> Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()<br /> and avoid a potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: use RCU protection in ovs_vport_cmd_fill_info()<br /> <br /> ovs_vport_cmd_fill_info() can be called without RTNL or RCU.<br /> <br /> Use RCU protection and dev_net_rcu() to avoid potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arp: use RCU protection in arp_xmit()<br /> <br /> arp_xmit() can be called without RTNL or RCU protection.<br /> <br /> Use RCU protection to avoid potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neighbour: use RCU protection in __neigh_notify()<br /> <br /> __neigh_notify() can be called without RTNL or RCU protection.<br /> <br /> Use RCU protection to avoid potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()<br /> <br /> On removal of the device or unloading of the kernel module a potential NULL<br /> pointer dereference occurs.<br /> <br /> The following sequence deletes the interface:<br /> <br /> brcmf_detach()<br /> brcmf_remove_interface()<br /> brcmf_del_if()<br /> <br /> Inside the brcmf_del_if() function the drvr-&gt;if2bss[ifidx] is updated to<br /> BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.<br /> <br /> After brcmf_remove_interface() call the brcmf_proto_detach() function is<br /> called providing the following sequence:<br /> <br /> brcmf_detach()<br /> brcmf_proto_detach()<br /> brcmf_proto_msgbuf_detach()<br /> brcmf_flowring_detach()<br /> brcmf_msgbuf_delete_flowring()<br /> brcmf_msgbuf_remove_flowring()<br /> brcmf_flowring_delete()<br /> brcmf_get_ifp()<br /> brcmf_txfinalize()<br /> <br /> Since brcmf_get_ip() can and actually will return NULL in this case the<br /> call to brcmf_txfinalize() will result in a NULL pointer dereference inside<br /> brcmf_txfinalize() when trying to update ifp-&gt;ndev-&gt;stats.tx_errors.<br /> <br /> This will only happen if a flowring still has an skb.<br /> <br /> Although the NULL pointer dereference has only been seen when trying to<br /> update the tx statistic, all other uses of the ifp pointer have been<br /> guarded as well with an early return if ifp is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Fix class @block_class&amp;#39;s subsystem refcount leakage<br /> <br /> blkcg_fill_root_iostats() iterates over @block_class&amp;#39;s devices by<br /> class_dev_iter_(init|next)(), but does not end iterating with<br /> class_dev_iter_exit(), so causes the class&amp;#39;s subsystem refcount leakage.<br /> <br /> Fix by ending the iterating with class_dev_iter_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics - fix crash when enabling pass-through port<br /> <br /> When enabling a pass-through port an interrupt might come before psmouse<br /> driver binds to the pass-through port. However synaptics sub-driver<br /> tries to access psmouse instance presumably associated with the<br /> pass-through port to figure out if only 1 byte of response or entire<br /> protocol packet needs to be forwarded to the pass-through port and may<br /> crash if psmouse instance has not been attached to the port yet.<br /> <br /> Fix the crash by introducing open() and close() methods for the port and<br /> check if the port is open before trying to access psmouse instance.<br /> Because psmouse calls serio_open() only after attaching psmouse instance<br /> to serio port instance this prevents the potential crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ast: astdp: Fix timeout for enabling video signal<br /> <br /> The ASTDP transmitter sometimes takes up to 1 second for enabling the<br /> video signal, while the timeout is only 200 msec. This results in a<br /> kernel error message. Increase the timeout to 1 second. An example<br /> of the error message is shown below.<br /> <br /> [ 697.084433] ------------[ cut here ]------------<br /> [ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))<br /> [ 697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast]<br /> [...]<br /> [ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast]<br /> [...]<br /> [ 697.415283] Call Trace:<br /> [ 697.420727] <br /> [ 697.425908] ? show_trace_log_lvl+0x196/0x2c0<br /> [ 697.433304] ? show_trace_log_lvl+0x196/0x2c0<br /> [ 697.440693] ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470<br /> [ 697.450115] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.458059] ? __warn.cold+0xaf/0xca<br /> [ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.472633] ? report_bug+0x134/0x1d0<br /> [ 697.479544] ? handle_bug+0x58/0x90<br /> [ 697.486127] ? exc_invalid_op+0x13/0x40<br /> [ 697.492975] ? asm_exc_invalid_op+0x16/0x20<br /> [ 697.500224] ? preempt_count_sub+0x14/0xc0<br /> [ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470<br /> [ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90<br /> [ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast]<br /> [ 697.550009] commit_tail+0xfe/0x1d0<br /> [ 697.556547] drm_atomic_helper_commit+0x198/0x1c0<br /> <br /> This is a cosmetical problem. Enabling the video signal still works<br /> even with the error message. The problem has always been present, but<br /> only recent versions of the ast driver warn about missing the timeout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix integer overflows on 32 bit systems<br /> <br /> On 32bit systems the addition operations in ipc_msg_alloc() can<br /> potentially overflow leading to memory corruption.<br /> Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.