Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()<br /> <br /> mwifiex_get_priv_by_id() returns the priv pointer corresponding to<br /> the bss_num and bss_type, but without checking if the priv is actually<br /> currently in use.<br /> Unused priv pointers do not have a wiphy attached to them which can<br /> lead to NULL pointer dereferences further down the callstack. Fix<br /> this by returning only used priv pointers which have priv-&gt;bss_mode<br /> set to something else than NL80211_IFTYPE_UNSPECIFIED.<br /> <br /> Said NULL pointer dereference happened when an Accesspoint was started<br /> with wpa_supplicant -i mlan0 with this config:<br /> <br /> network={<br /> ssid="somessid"<br /> mode=2<br /> frequency=2412<br /> key_mgmt=WPA-PSK WPA-PSK-SHA256<br /> proto=RSN<br /> group=CCMP<br /> pairwise=CCMP<br /> psk="12345678"<br /> }<br /> <br /> When waiting for the AP to be established, interrupting wpa_supplicant<br /> with and starting it again this happens:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140<br /> | Mem abort info:<br /> | ESR = 0x0000000096000004<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x04: level 0 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> | CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000<br /> | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000<br /> | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio<br /> +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs<br /> +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6<br /> | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18<br /> | Hardware name: somemachine (DT)<br /> | Workqueue: events sdio_irq_work<br /> | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]<br /> | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]<br /> | sp : ffff8000818b3a70<br /> | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004<br /> | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9<br /> | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000<br /> | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000<br /> | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517<br /> | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1<br /> | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157<br /> | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124<br /> | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000<br /> | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000<br /> | Call trace:<br /> | mwifiex_get_cfp+0xd8/0x15c [mwifiex]<br /> | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]<br /> | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]<br /> | mwifiex_process_sta_event+0x298/0xf0c [mwifiex]<br /> | mwifiex_process_event+0x110/0x238 [mwifiex]<br /> | mwifiex_main_process+0x428/0xa44 [mwifiex]<br /> | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]<br /> | process_sdio_pending_irqs+0x64/0x1b8<br /> | sdio_irq_work+0x4c/0x7c<br /> | process_one_work+0x148/0x2a0<br /> | worker_thread+0x2fc/0x40c<br /> | kthread+0x110/0x114<br /> | ret_from_fork+0x10/0x20<br /> | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)<br /> | ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (adc128d818) Fix underflows seen when writing limit attributes<br /> <br /> DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large<br /> negative number such as -9223372036854775808 is provided by the user.<br /> Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv<br /> <br /> The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel<br /> crash when we try to hot-unplug/disable the PCIe switch/bridge from<br /> the PHB.<br /> <br /> The crash occurs because although the MSI data structure has been<br /> released during disable/hot-unplug path and it has been assigned<br /> with NULL, still during unregistration the code was again trying to<br /> explicitly disable the MSI which causes the NULL pointer dereference and<br /> kernel crash.<br /> <br /> The patch fixes the check during unregistration path to prevent invoking<br /> pci_disable_msi/msix() since its data structure is already freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fou: Fix null-ptr-deref in GRO.<br /> <br /> We observed a null-ptr-deref in fou_gro_receive() while shutting down<br /> a host. [0]<br /> <br /> The NULL pointer is sk-&gt;sk_user_data, and the offset 8 is of protocol<br /> in struct fou.<br /> <br /> When fou_release() is called due to netns dismantle or explicit tunnel<br /> teardown, udp_tunnel_sock_release() sets NULL to sk-&gt;sk_user_data.<br /> Then, the tunnel socket is destroyed after a single RCU grace period.<br /> <br /> So, in-flight udp4_gro_receive() could find the socket and execute the<br /> FOU GRO handler, where sk-&gt;sk_user_data could be NULL.<br /> <br /> Let&amp;#39;s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL<br /> checks in FOU GRO handlers.<br /> <br /> [0]:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0<br /> SMP PTI<br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1<br /> Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017<br /> RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]<br /> Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42<br /> RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297<br /> RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010<br /> RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08<br /> RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002<br /> R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400<br /> R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0<br /> FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)<br /> ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)<br /> ? no_context (arch/x86/mm/fault.c:752)<br /> ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)<br /> ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)<br /> ? fou_gro_receive (net/ipv4/fou.c:233) [fou]<br /> udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)<br /> udp4_gro_receive (net/ipv4/udp_offload.c:604)<br /> inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))<br /> dev_gro_receive (net/core/dev.c:6035 (discriminator 4))<br /> napi_gro_receive (net/core/dev.c:6170)<br /> ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]<br /> ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]<br /> napi_poll (net/core/dev.c:6847)<br /> net_rx_action (net/core/dev.c:6917)<br /> __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)<br /> asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)<br /> <br /> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)<br /> irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)<br /> common_interrupt (arch/x86/kernel/irq.c:239)<br /> asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)<br /> RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)<br /> Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00<br /> RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246<br /> RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900<br /> RDX: ffff93daee800000 RSI: ffff93d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Add netif_device_attach/detach into PF reset flow<br /> <br /> Ethtool callbacks can be executed while reset is in progress and try to<br /> access deleted resources, e.g. getting coalesce settings can result in a<br /> NULL pointer dereference seen below.<br /> <br /> Reproduction steps:<br /> Once the driver is fully initialized, trigger reset:<br /> # echo 1 &gt; /sys/class/net//device/reset<br /> when reset is in progress try to get coalesce settings using ethtool:<br /> # ethtool -c <br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7<br /> RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]<br /> RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206<br /> RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000<br /> R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40<br /> FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ice_get_coalesce+0x17/0x30 [ice]<br /> coalesce_prepare_data+0x61/0x80<br /> ethnl_default_doit+0xde/0x340<br /> genl_family_rcv_msg_doit+0xf2/0x150<br /> genl_rcv_msg+0x1b3/0x2c0<br /> netlink_rcv_skb+0x5b/0x110<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x19c/0x290<br /> netlink_sendmsg+0x222/0x490<br /> __sys_sendto+0x1df/0x1f0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x82/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7faee60d8e27<br /> <br /> Calling netif_device_detach() before reset makes the net core not call<br /> the driver when ethtool command is issued, the attempt to execute an<br /> ethtool command during reset will result in the following message:<br /> <br /> netlink error: No such device<br /> <br /> instead of NULL pointer dereference. Once reset is done and<br /> ice_rebuild() is executing, the netif_device_attach() is called to allow<br /> for ethtool operations to occur again in a safe manner.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double put of @cfile in smb2_rename_path()<br /> <br /> If smb2_set_path_attr() is called with a valid @cfile and returned<br /> -EINVAL, we need to call cifs_get_writable_path() again as the<br /> reference of @cfile was already dropped by previous smb2_compound_op()<br /> call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix double free of &amp;#39;buf&amp;#39; in error path<br /> <br /> smatch warning:<br /> drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of &amp;#39;buf&amp;#39;<br /> <br /> In fastrpc_req_mmap() error path, the fastrpc buffer is freed in<br /> fastrpc_req_munmap_impl() if unmap is successful.<br /> <br /> But in the end, there is an unconditional call to fastrpc_buf_free().<br /> So the above case triggers the double free of fastrpc buf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Set the max subreq size for cache writes to MAX_RW_COUNT<br /> <br /> Set the maximum size of a subrequest that writes to cachefiles to be<br /> MAX_RW_COUNT so that we don&amp;#39;t overrun the maximum write we can make to the<br /> backing filesystem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()<br /> <br /> This adds a check before freeing the rx-&gt;skb in flush and close<br /> functions to handle the kernel crash seen while removing driver after FW<br /> download fails or before FW download completes.<br /> <br /> dmesg log:<br /> [ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080<br /> [ 54.643398] Mem abort info:<br /> [ 54.646204] ESR = 0x0000000096000004<br /> [ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 54.655286] SET = 0, FnV = 0<br /> [ 54.658348] EA = 0, S1PTW = 0<br /> [ 54.661498] FSC = 0x04: level 0 translation fault<br /> [ 54.666391] Data abort info:<br /> [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000<br /> [ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000<br /> [ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse<br /> [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2<br /> [ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT)<br /> [ 54.744368] Workqueue: hci0 hci_power_on<br /> [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 54.757249] pc : kfree_skb_reason+0x18/0xb0<br /> [ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart]<br /> [ 54.782921] sp : ffff8000805ebca0<br /> [ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000<br /> [ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230<br /> [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92<br /> [ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff<br /> [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857<br /> [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642<br /> [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688<br /> [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac<br /> [ 54.857599] Call trace:<br /> [ 54.857601] kfree_skb_reason+0x18/0xb0<br /> [ 54.863878] btnxpuart_flush+0x40/0x58 [btnxpuart]<br /> [ 54.863888] hci_dev_open_sync+0x3a8/0xa04<br /> [ 54.872773] hci_power_on+0x54/0x2e4<br /> [ 54.881832] process_one_work+0x138/0x260<br /> [ 54.881842] worker_thread+0x32c/0x438<br /> [ 54.881847] kthread+0x118/0x11c<br /> [ 54.881853] ret_from_fork+0x10/0x20<br /> [ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400)<br /> [ 54.896410] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()<br /> <br /> null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)<br /> and parse_lease_state() return NULL.<br /> <br /> Fix this by check if &amp;#39;lease_ctx_info&amp;#39; is NULL.<br /> <br /> Additionally, remove the redundant parentheses in<br /> parse_durable_handle_context().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()<br /> <br /> When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the<br /> first one sets &amp;#39;ubq-&gt;ubq_daemon&amp;#39; to NULL, and the second one triggers<br /> WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference<br /> issue.<br /> <br /> Fix it by adding the check in ublk_ctrl_start_recovery() and return<br /> immediately in case of zero &amp;#39;ub-&gt;nr_queues_ready&amp;#39;.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x75/0x170<br /> ? exc_page_fault+0x64/0x140<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180<br /> ublk_ctrl_uring_cmd+0x4f7/0x6c0<br /> ? pick_next_task_idle+0x26/0x40<br /> io_uring_cmd+0x9a/0x1b0<br /> io_issue_sqe+0x193/0x3f0<br /> io_wq_submit_work+0x9b/0x390<br /> io_worker_handle_work+0x165/0x360<br /> io_wq_worker+0xcb/0x2f0<br /> ? finish_task_switch.isra.0+0x203/0x290<br /> ? finish_task_switch.isra.0+0x203/0x290<br /> ? __pfx_io_wq_worker+0x10/0x10<br /> ret_from_fork+0x2d/0x50<br /> ? __pfx_io_wq_worker+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fix kernel crash if commands allocation fails<br /> <br /> If the commands allocation fails in nvmet_tcp_alloc_cmds()<br /> the kernel crashes in nvmet_tcp_release_queue_work() because of<br /> a NULL pointer dereference.<br /> <br /> nvmet: failed to install queue 0 cntlid 1 ret 6<br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000008<br /> <br /> Fix the bug by setting queue-&gt;nr_cmds to zero in case<br /> nvmet_tcp_alloc_cmd() fails.