Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.<br /> <br /> SIOCBRDELIF is passed to dev_ioctl() first and later forwarded to<br /> br_ioctl_call(), which causes unnecessary RTNL dance and the splat<br /> below [0] under RTNL pressure.<br /> <br /> Let&amp;#39;s say Thread A is trying to detach a device from a bridge and<br /> Thread B is trying to remove the bridge.<br /> <br /> In dev_ioctl(), Thread A bumps the bridge device&amp;#39;s refcnt by<br /> netdev_hold() and releases RTNL because the following br_ioctl_call()<br /> also re-acquires RTNL.<br /> <br /> In the race window, Thread B could acquire RTNL and try to remove<br /> the bridge device. Then, rtnl_unlock() by Thread B will release RTNL<br /> and wait for netdev_put() by Thread A.<br /> <br /> Thread A, however, must hold RTNL after the unlock in dev_ifsioc(),<br /> which may take long under RTNL pressure, resulting in the splat by<br /> Thread B.<br /> <br /> Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR)<br /> ---------------------- ----------------------<br /> sock_ioctl sock_ioctl<br /> `- sock_do_ioctl `- br_ioctl_call<br /> `- dev_ioctl `- br_ioctl_stub<br /> |- rtnl_lock |<br /> |- dev_ifsioc &amp;#39;<br /> &amp;#39; |- dev = __dev_get_by_name(...)<br /> |- netdev_hold(dev, ...) .<br /> / |- rtnl_unlock ------. |<br /> | |- br_ioctl_call `---&gt; |- rtnl_lock<br /> Race | | `- br_ioctl_stub |- br_del_bridge<br /> Window | | | |- dev = __dev_get_by_name(...)<br /> | | | May take long | `- br_dev_delete(dev, ...)<br /> | | | under RTNL pressure | `- unregister_netdevice_queue(dev, ...)<br /> | | | | `- rtnl_unlock<br /> \ | |- rtnl_lock

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmxnet3: unregister xdp rxq info in the reset path<br /> <br /> vmxnet3 does not unregister xdp rxq info in the<br /> vmxnet3_reset_work() code path as vmxnet3_rq_destroy()<br /> is not invoked in this code path. So, we get below message with a<br /> backtrace.<br /> <br /> Missing unregister, handled but fix driver<br /> WARNING: CPU:48 PID: 500 at net/core/xdp.c:182<br /> __xdp_rxq_info_reg+0x93/0xf0<br /> <br /> This patch fixes the problem by moving the unregister<br /> code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Use kernel helpers for hex dumps<br /> <br /> Previously, when the driver was printing hex dumps, the buffer was cast<br /> to an 8 byte long and printed using string formatters. If the buffer<br /> size was not a multiple of 8 then a read buffer overflow was possible.<br /> <br /> Therefore, create a new ibmvnic function that loops over a buffer and<br /> calls hex_dump_to_buffer instead.<br /> <br /> This patch address KASAN reports like the one below:<br /> ibmvnic 30000003 env3: Login Buffer:<br /> ibmvnic 30000003 env3: 01000000af000000<br /> <br /> ibmvnic 30000003 env3: 2e6d62692e736261<br /> ibmvnic 30000003 env3: 65050003006d6f63<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]<br /> Read of size 8 at addr c0000001331a9aa8 by task ip/17681<br /> <br /> Allocated by task 17681:<br /> <br /> ibmvnic_login+0x2f0/0xffc [ibmvnic]<br /> ibmvnic_open+0x148/0x308 [ibmvnic]<br /> __dev_open+0x1ac/0x304<br /> <br /> The buggy address is located 168 bytes inside of<br /> allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)<br /> <br /> =================================================================<br /> ibmvnic 30000003 env3: 000000000033766e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vkms: Fix use after free and double free on init error<br /> <br /> If the driver initialization fails, the vkms_exit() function might<br /> access an uninitialized or freed default_config pointer and it might<br /> double free it.<br /> <br /> Fix both possible errors by initializing default_config only when the<br /> driver initialization succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Fix kernel panic during FW release<br /> <br /> This fixes a kernel panic seen during release FW in a stress test<br /> scenario where WLAN and BT FW download occurs simultaneously, and due to<br /> a HW bug, chip sends out only 1 bootloader signatures.<br /> <br /> When driver receives the bootloader signature, it enters FW download<br /> mode, but since no consequtive bootloader signatures seen, FW file is<br /> not requested.<br /> <br /> After 60 seconds, when FW download times out, release_firmware causes a<br /> kernel panic.<br /> <br /> [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573<br /> [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000<br /> [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000<br /> [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP<br /> [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev<br /> [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1<br /> [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT)<br /> [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2602.010191] pc : _raw_spin_lock+0x34/0x68<br /> [ 2602.010201] lr : free_fw_priv+0x20/0xfc<br /> [ 2602.020561] sp : ffff800089363b30<br /> [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000<br /> [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000<br /> [ 2602.020577] x23: ffff0000dc856f38<br /> [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000<br /> [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000<br /> [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480<br /> [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002<br /> [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30<br /> [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000<br /> [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573<br /> [ 2602.083354] Call trace:<br /> [ 2602.083356] _raw_spin_lock+0x34/0x68<br /> [ 2602.083364] release_firmware+0x48/0x6c<br /> [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart]<br /> [ 2602.083383] hci_dev_open_sync+0xf0/0xa34<br /> [ 2602.083391] hci_dev_open+0xd8/0x178<br /> [ 2602.083399] hci_sock_ioctl+0x3b0/0x590<br /> [ 2602.083405] sock_do_ioctl+0x60/0x118<br /> [ 2602.083413] sock_ioctl+0x2f4/0x374<br /> [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0<br /> [ 2602.091437] invoke_syscall+0x48/0x110<br /> [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 2602.091452] do_el0_svc+0x1c/0x28<br /> [ 2602.091457] el0_svc+0x40/0xe4<br /> [ 2602.091465] el0t_64_sync_handler+0x120/0x12c<br /> [ 2602.091470] el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: fix Tx L4 checksum<br /> <br /> The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol.<br /> There was a bug to set Tx checksum flag for the other protocol that results<br /> in Tx ring hang. Fix to compute software checksum for these packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix race condition when gathering fdinfo group samples<br /> <br /> Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to<br /> protect access to groups with an xarray lock, which could lead to<br /> use-after-free errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init<br /> <br /> devm_kasprintf() calls can return null pointers on failure.<br /> But some return values were not checked in zynqmp_audio_init().<br /> <br /> Add NULL check in zynqmp_audio_init(), avoid referencing null<br /> pointers in the subsequent code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()<br /> <br /> Instead of attempting the same mutex twice, lock and unlock it.<br /> <br /> This bug has been detected by the Clang thread-safety analyzer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()<br /> <br /> There are actually 2 problems:<br /> - deleting the last element doesn&amp;#39;t require the memmove of elements<br /> [i + 1, end) over it. Actually, element i+1 is out of bounds.<br /> - The memmove itself should move size - i - 1 elements, because the last<br /> element is out of bounds.<br /> <br /> The out-of-bounds element still remains out of bounds after being<br /> accessed, so the problem is only that we touch it, not that it becomes<br /> in active use. But I suppose it can lead to issues if the out-of-bounds<br /> element is part of an unmapped page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix NULL pointer dereference in l3mdev_l3_rcv<br /> <br /> When delete l3s ipvlan:<br /> <br /> ip link del link eth0 ipvlan1 type ipvlan mode l3s<br /> <br /> This may cause a null pointer dereference:<br /> <br /> Call trace:<br /> ip_rcv_finish+0x48/0xd0<br /> ip_rcv+0x5c/0x100<br /> __netif_receive_skb_one_core+0x64/0xb0<br /> __netif_receive_skb+0x20/0x80<br /> process_backlog+0xb4/0x204<br /> napi_poll+0xe8/0x294<br /> net_rx_action+0xd8/0x22c<br /> __do_softirq+0x12c/0x354<br /> <br /> This is because l3mdev_l3_rcv() visit dev-&gt;l3mdev_ops after<br /> ipvlan_l3s_unregister() assign the dev-&gt;l3mdev_ops to NULL. The process<br /> like this:<br /> <br /> (CPU1) | (CPU2)<br /> l3mdev_l3_rcv() |<br /> check dev-&gt;priv_flags: |<br /> master = skb-&gt;dev; |<br /> |<br /> | ipvlan_l3s_unregister()<br /> | set dev-&gt;priv_flags<br /> | dev-&gt;l3mdev_ops = NULL;<br /> |<br /> visit master-&gt;l3mdev_ops |<br /> <br /> To avoid this by do not set dev-&gt;l3mdev_ops when unregister l3s ipvlan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: check xdp prog when set bond mode<br /> <br /> Following operations can trigger a warning[1]:<br /> <br /> ip netns add ns1<br /> ip netns exec ns1 ip link add bond0 type bond mode balance-rr<br /> ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp<br /> ip netns exec ns1 ip link set bond0 type bond mode broadcast<br /> ip netns del ns1<br /> <br /> When delete the namespace, dev_xdp_uninstall() is called to remove xdp<br /> program on bond dev, and bond_xdp_set() will check the bond mode. If bond<br /> mode is changed after attaching xdp program, the warning may occur.<br /> <br /> Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode<br /> with xdp program attached is not good. Add check for xdp program when set<br /> bond mode.<br /> <br /> [1]<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930<br /> Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ...<br /> RSP: 0018:ffffc90000063d80 EFLAGS: 00000282<br /> RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff<br /> RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48<br /> RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb<br /> R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8<br /> R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000<br /> FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __warn+0x83/0x130<br /> ? unregister_netdevice_many_notify+0x8d9/0x930<br /> ? report_bug+0x18e/0x1a0<br /> ? handle_bug+0x54/0x90<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? unregister_netdevice_many_notify+0x8d9/0x930<br /> ? bond_net_exit_batch_rtnl+0x5c/0x90<br /> cleanup_net+0x237/0x3d0<br /> process_one_work+0x163/0x390<br /> worker_thread+0x293/0x3b0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xec/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ---[ end trace 0000000000000000 ]---