Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix increasing MSI-X on VF<br /> <br /> Increasing MSI-X value on a VF leads to invalid memory operations. This<br /> is caused by not reallocating some arrays.<br /> <br /> Reproducer:<br /> modprobe ice<br /> echo 0 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe<br /> echo 1 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_numvfs<br /> echo 17 &gt; /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count<br /> <br /> Default MSI-X is 16, so 17 and above triggers this issue.<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> Read of size 8 at addr ffff8888b937d180 by task bash/28433<br /> (...)<br /> <br /> Call Trace:<br /> (...)<br /> ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> kasan_report+0xed/0x120<br /> ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> ice_vsi_cfg_def+0x3360/0x4770 [ice]<br /> ? mutex_unlock+0x83/0xd0<br /> ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice]<br /> ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice]<br /> ice_vsi_cfg+0x7f/0x3b0 [ice]<br /> ice_vf_reconfig_vsi+0x114/0x210 [ice]<br /> ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice]<br /> sriov_vf_msix_count_store+0x21c/0x300<br /> (...)<br /> <br /> Allocated by task 28201:<br /> (...)<br /> ice_vsi_cfg_def+0x1c8e/0x4770 [ice]<br /> ice_vsi_cfg+0x7f/0x3b0 [ice]<br /> ice_vsi_setup+0x179/0xa30 [ice]<br /> ice_sriov_configure+0xcaa/0x1520 [ice]<br /> sriov_numvfs_store+0x212/0x390<br /> (...)<br /> <br /> To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This<br /> causes the required arrays to be reallocated taking the new queue count<br /> into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq<br /> before ice_vsi_rebuild(), so that realloc uses the newly set queue<br /> count.<br /> <br /> Additionally, ice_vsi_rebuild() does not remove VSI filters<br /> (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer<br /> necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix possible badness in FREE_STATEID<br /> <br /> When multiple FREE_STATEIDs are sent for the same delegation stateid,<br /> it can lead to a possible either use-after-free or counter refcount<br /> underflow errors.<br /> <br /> In nfsd4_free_stateid() under the client lock we find a delegation<br /> stateid, however the code drops the lock before calling nfs4_put_stid(),<br /> that allows another FREE_STATE to find the stateid again. The first one<br /> will proceed to then free the stateid which leads to either<br /> use-after-free or decrementing already zeroed counter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tipd: Free IRQ only if it was requested before<br /> <br /> In polling mode, if no IRQ was requested there is no need to free it.<br /> Call devm_free_irq() only if client-&gt;irq is set. This fixes the warning<br /> caused by the tps6598x module removal:<br /> <br /> WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c<br /> ...<br /> ...<br /> Call trace:<br /> devm_free_irq+0x80/0x8c<br /> tps6598x_remove+0x28/0x88 [tps6598x]<br /> i2c_device_remove+0x2c/0x9c<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1cc/0x228<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> i2c_del_driver+0x54/0x64<br /> tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]<br /> __arm64_sys_delete_module+0x184/0x264<br /> invoke_syscall+0x48/0x110<br /> el0_svc_common.constprop.0+0xc8/0xe8<br /> do_el0_svc+0x20/0x2c<br /> el0_svc+0x28/0x98<br /> el0t_64_sync_handler+0x13c/0x158<br /> el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: bus: Fix double free in driver API bus_register()<br /> <br /> For bus_register(), any error which happens after kset_register() will<br /> cause that @priv are freed twice, fixed by setting @priv with NULL after<br /> the first free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix UAF in async decryption<br /> <br /> Doing an async decryption (large read) crashes with a<br /> slab-use-after-free way down in the crypto API.<br /> <br /> Reproducer:<br /> # mount.cifs -o ...,seal,esize=1 //srv/share /mnt<br /> # dd if=/mnt/largefile of=/dev/null<br /> ...<br /> [ 194.196391] ==================================================================<br /> [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110<br /> [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899<br /> [ 194.197707]<br /> [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43<br /> [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014<br /> [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]<br /> [ 194.200032] Call Trace:<br /> [ 194.200191] <br /> [ 194.200327] dump_stack_lvl+0x4e/0x70<br /> [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.200809] print_report+0x174/0x505<br /> [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 194.201352] ? srso_return_thunk+0x5/0x5f<br /> [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0<br /> [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202128] kasan_report+0xc8/0x150<br /> [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202616] gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202863] ghash_update+0x184/0x210<br /> [ 194.203103] shash_ahash_update+0x184/0x2a0<br /> [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10<br /> [ 194.203651] ? srso_return_thunk+0x5/0x5f<br /> [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340<br /> [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140<br /> [ 194.204434] crypt_message+0xec1/0x10a0 [cifs]<br /> [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs]<br /> [ 194.208507] ? srso_return_thunk+0x5/0x5f<br /> [ 194.209205] ? srso_return_thunk+0x5/0x5f<br /> [ 194.209925] ? srso_return_thunk+0x5/0x5f<br /> [ 194.210443] ? srso_return_thunk+0x5/0x5f<br /> [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs]<br /> [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]<br /> [ 194.214670] ? srso_return_thunk+0x5/0x5f<br /> [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]<br /> <br /> This is because TFM is being used in parallel.<br /> <br /> Fix this by allocating a new AEAD TFM for async decryption, but keep<br /> the existing one for synchronous READ cases (similar to what is done<br /> in smb3_calc_signature()).<br /> <br /> Also remove the calls to aead_request_set_callback() and<br /> crypto_wait_req() since it&amp;#39;s always going to be a synchronous operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c<br /> <br /> Fix potential dereferencing of ERR_PTR() in find_format_by_pix()<br /> and uvc_v4l2_enum_format().<br /> <br /> Fix the following smatch errors:<br /> <br /> drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix()<br /> error: &amp;#39;fmtdesc&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format()<br /> error: &amp;#39;fmtdesc&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> Also, fix similar issue in uvc_v4l2_try_format() for potential<br /> dereferencing of ERR_PTR().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Do not bring the device up after non-fatal error<br /> <br /> Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal")<br /> changed igb_io_error_detected() to ignore non-fatal pcie errors in order<br /> to avoid hung task that can happen when igb_down() is called multiple<br /> times. This caused an issue when processing transient non-fatal errors.<br /> igb_io_resume(), which is called after igb_io_error_detected(), assumes<br /> that device is brought down by igb_io_error_detected() if the interface<br /> is up. This resulted in panic with stacktrace below.<br /> <br /> [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down<br /> [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0<br /> [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)<br /> [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000<br /> [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000<br /> [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message<br /> [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.<br /> [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message<br /> [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message<br /> [ T292] ------------[ cut here ]------------<br /> [ T292] kernel BUG at net/core/dev.c:6539!<br /> [ T292] invalid opcode: 0000 [#1] PREEMPT SMP<br /> [ T292] RIP: 0010:napi_enable+0x37/0x40<br /> [ T292] Call Trace:<br /> [ T292] <br /> [ T292] ? die+0x33/0x90<br /> [ T292] ? do_trap+0xdc/0x110<br /> [ T292] ? napi_enable+0x37/0x40<br /> [ T292] ? do_error_trap+0x70/0xb0<br /> [ T292] ? napi_enable+0x37/0x40<br /> [ T292] ? napi_enable+0x37/0x40<br /> [ T292] ? exc_invalid_op+0x4e/0x70<br /> [ T292] ? napi_enable+0x37/0x40<br /> [ T292] ? asm_exc_invalid_op+0x16/0x20<br /> [ T292] ? napi_enable+0x37/0x40<br /> [ T292] igb_up+0x41/0x150<br /> [ T292] igb_io_resume+0x25/0x70<br /> [ T292] report_resume+0x54/0x70<br /> [ T292] ? report_frozen_detected+0x20/0x20<br /> [ T292] pci_walk_bus+0x6c/0x90<br /> [ T292] ? aer_print_port_info+0xa0/0xa0<br /> [ T292] pcie_do_recovery+0x22f/0x380<br /> [ T292] aer_process_err_devices+0x110/0x160<br /> [ T292] aer_isr+0x1c1/0x1e0<br /> [ T292] ? disable_irq_nosync+0x10/0x10<br /> [ T292] irq_thread_fn+0x1a/0x60<br /> [ T292] irq_thread+0xe3/0x1a0<br /> [ T292] ? irq_set_affinity_notifier+0x120/0x120<br /> [ T292] ? irq_affinity_notify+0x100/0x100<br /> [ T292] kthread+0xe2/0x110<br /> [ T292] ? kthread_complete_and_exit+0x20/0x20<br /> [ T292] ret_from_fork+0x2d/0x50<br /> [ T292] ? kthread_complete_and_exit+0x20/0x20<br /> [ T292] ret_from_fork_asm+0x11/0x20<br /> [ T292] <br /> <br /> To fix this issue igb_io_resume() checks if the interface is running and<br /> the device is not down this means igb_io_error_detected() did not bring<br /> the device down and there is no need to bring it up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix macvlan leak by synchronizing access to mac_filter_hash<br /> <br /> This patch addresses a macvlan leak issue in the i40e driver caused by<br /> concurrent access to vsi-&gt;mac_filter_hash. The leak occurs when multiple<br /> threads attempt to modify the mac_filter_hash simultaneously, leading to<br /> inconsistent state and potential memory leaks.<br /> <br /> To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing<br /> vf-&gt;default_lan_addr.addr with spin_lock/unlock_bh(&amp;vsi-&gt;mac_filter_hash_lock),<br /> ensuring atomic operations and preventing concurrent access.<br /> <br /> Additionally, we add lockdep_assert_held(&amp;vsi-&gt;mac_filter_hash_lock) in<br /> i40e_add_mac_filter() to help catch similar issues in the future.<br /> <br /> Reproduction steps:<br /> 1. Spawn VFs and configure port vlan on them.<br /> 2. Trigger concurrent macvlan operations (e.g., adding and deleting<br /> portvlan and/or mac filters).<br /> 3. Observe the potential memory leak and inconsistent state in the<br /> mac_filter_hash.<br /> <br /> This synchronization ensures the integrity of the mac_filter_hash and prevents<br /> the described leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change<br /> <br /> rfcomm_sk_state_change attempts to use sock_lock so it must never be<br /> called with it locked but rfcomm_sock_ioctl always attempt to lock it<br /> causing the following trace:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor386/5093 is trying to acquire lock:<br /> ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]<br /> ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73<br /> <br /> but task is already holding lock:<br /> ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: br_netfilter: fix panic with metadata_dst skb<br /> <br /> Fix a kernel panic in the br_netfilter module when sending untagged<br /> traffic via a VxLAN device.<br /> This happens during the check for fragmentation in br_nf_dev_queue_xmit.<br /> <br /> It is dependent on:<br /> 1) the br_netfilter module being loaded;<br /> 2) net.bridge.bridge-nf-call-iptables set to 1;<br /> 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;<br /> 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded<br /> <br /> When forwarding the untagged packet to the VxLAN bridge port, before<br /> the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and<br /> changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type<br /> of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.<br /> <br /> Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there&amp;#39;s a check<br /> for frames that needs to be fragmented: frames with higher MTU than the<br /> VxLAN device end up calling br_nf_ip_fragment, which in turns call<br /> ip_skb_dst_mtu.<br /> <br /> The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst<br /> with valid dst-&gt;dev, thus the crash.<br /> <br /> This case was never supported in the first place, so drop the packet<br /> instead.<br /> <br /> PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.<br /> [ 176.291791] Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000110<br /> [ 176.292101] Mem abort info:<br /> [ 176.292184] ESR = 0x0000000096000004<br /> [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 176.292530] SET = 0, FnV = 0<br /> [ 176.292709] EA = 0, S1PTW = 0<br /> [ 176.292862] FSC = 0x04: level 0 translation fault<br /> [ 176.293013] Data abort info:<br /> [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000<br /> [ 176.294166] [0000000000000110] pgd=0000000000000000,<br /> p4d=0000000000000000<br /> [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth<br /> br_netfilter bridge stp llc ipv6 crct10dif_ce<br /> [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted<br /> 6.8.0-rc3-g5b3fbd61b9d1 #2<br /> [ 176.296314] Hardware name: linux,dummy-virt (DT)<br /> [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS<br /> BTYPE=--)<br /> [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]<br /> [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]<br /> [ 176.297636] sp : ffff800080003630<br /> [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:<br /> ffff6828c49ad9f8<br /> [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:<br /> 00000000000003e8<br /> [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:<br /> ffff6828c3b16d28<br /> [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:<br /> 0000000000000014<br /> [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:<br /> 0000000095744632<br /> [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:<br /> ffffb7e137926a70<br /> [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :<br /> 0000000000000000<br /> [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :<br /> f20e0100bebafeca<br /> [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :<br /> 0000000000000000<br /> [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :<br /> ffff6828c7f918f0<br /> [ 176.300889] Call trace:<br /> [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]<br /> [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]<br /> [ 176.301703] nf_hook_slow+0x48/0x124<br /> [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge]<br /> [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter]<br /> [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter]<br /> [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]<br /> [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter]<br /> [ 176.303359] nf_hook_slow+0x48/0x124<br /> [ 176.303<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()<br /> <br /> On the node of an NFS client, some files saved in the mountpoint of the<br /> NFS server were copied to another location of the same NFS server.<br /> Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference<br /> crash with the following syslog:<br /> <br /> [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116<br /> [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116<br /> [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058<br /> [232066.588586] Mem abort info:<br /> [232066.588701] ESR = 0x0000000096000007<br /> [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [232066.589084] SET = 0, FnV = 0<br /> [232066.589216] EA = 0, S1PTW = 0<br /> [232066.589340] FSC = 0x07: level 3 translation fault<br /> [232066.589559] Data abort info:<br /> [232066.589683] ISV = 0, ISS = 0x00000007<br /> [232066.589842] CM = 0, WnR = 0<br /> [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400<br /> [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000<br /> [232066.590757] Internal error: Oops: 96000007 [#1] SMP<br /> [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2<br /> [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs<br /> [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1<br /> [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06<br /> [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]<br /> [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]<br /> [232066.598595] sp : ffff8000f568fc70<br /> [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000<br /> [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001<br /> [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050<br /> [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000<br /> [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000<br /> [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6<br /> [232066.600498] x11: 00000000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: Fix a NULL pointer dereference issue in fbcon_putcs<br /> <br /> syzbot has found a NULL pointer dereference bug in fbcon.<br /> Here is the simplified C reproducer:<br /> <br /> struct param {<br /> uint8_t type;<br /> struct tiocl_selection ts;<br /> };<br /> <br /> int main()<br /> {<br /> struct fb_con2fbmap con2fb;<br /> struct param param;<br /> <br /> int fd = open("/dev/fb1", 0, 0);<br /> <br /> con2fb.console = 0x19;<br /> con2fb.framebuffer = 0;<br /> ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb);<br /> <br /> param.type = 2;<br /> param.ts.xs = 0; param.ts.ys = 0;<br /> param.ts.xe = 0; param.ts.ye = 0;<br /> param.ts.sel_mode = 0;<br /> <br /> int fd1 = open("/dev/tty1", O_RDWR, 0);<br /> ioctl(fd1, TIOCLINUX, &amp;param);<br /> <br /> con2fb.console = 1;<br /> con2fb.framebuffer = 0;<br /> ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb);<br /> <br /> return 0;<br /> }<br /> <br /> After calling ioctl(fd1, TIOCLINUX, &amp;param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb)<br /> causes the kernel to follow a different execution path:<br /> <br /> set_con2fb_map<br /> -&gt; con2fb_init_display<br /> -&gt; fbcon_set_disp<br /> -&gt; redraw_screen<br /> -&gt; hide_cursor<br /> -&gt; clear_selection<br /> -&gt; highlight<br /> -&gt; invert_screen<br /> -&gt; do_update_region<br /> -&gt; fbcon_putcs<br /> -&gt; ops-&gt;putcs<br /> <br /> Since ops-&gt;putcs is a NULL pointer, this leads to a kernel panic.<br /> To prevent this, we need to call set_blitting_type() within set_con2fb_map()<br /> to properly initialize ops-&gt;putcs.