Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Handle enclosure with just a primary component gracefully<br /> <br /> This reverts commit 3fe97ff3d949 ("scsi: ses: Don&amp;#39;t attach if enclosure<br /> has no components") and introduces proper handling of case where there are<br /> no detected secondary components, but primary component (enumerated in<br /> num_enclosures) does exist. That fix was originally proposed by Ding Hui<br /> .<br /> <br /> Completely ignoring devices that have one primary enclosure and no<br /> secondary one results in ses_intf_add() bailing completely<br /> <br /> scsi 2:0:0:254: enclosure has no enumerated components<br /> scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such<br /> <br /> even on valid configurations with 1 primary and 0 secondary enclosures as<br /> below:<br /> <br /> # sg_ses /dev/sg0<br /> 3PARdata SES 3321<br /> Supported diagnostic pages:<br /> Supported Diagnostic Pages [sdp] [0x0]<br /> Configuration (SES) [cf] [0x1]<br /> Short Enclosure Status (SES) [ses] [0x8]<br /> # sg_ses -p cf /dev/sg0<br /> 3PARdata SES 3321<br /> Configuration diagnostic page:<br /> number of secondary subenclosures: 0<br /> generation code: 0x0<br /> enclosure descriptor list<br /> Subenclosure identifier: 0 [primary]<br /> relative ES process id: 0, number of ES processes: 1<br /> number of type descriptor headers: 1<br /> enclosure logical identifier (hex): 20000002ac02068d<br /> enclosure vendor: 3PARdata product: VV rev: 3321<br /> type descriptor header and text list<br /> Element type: Unspecified, subenclosure id: 0<br /> number of possible elements: 1<br /> <br /> The changelog for the original fix follows<br /> <br /> =====<br /> We can get a crash when disconnecting the iSCSI session,<br /> the call trace like this:<br /> <br /> [ffff00002a00fb70] kfree at ffff00000830e224<br /> [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4<br /> [ffff00002a00fbd0] device_del at ffff0000086b6a98<br /> [ffff00002a00fc50] device_unregister at ffff0000086b6d58<br /> [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c<br /> [ffff00002a00fca0] scsi_remove_device at ffff000008706134<br /> [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4<br /> [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0<br /> [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4<br /> [ffff00002a00fdb0] process_one_work at ffff00000810f35c<br /> [ffff00002a00fe00] worker_thread at ffff00000810f648<br /> [ffff00002a00fe70] kthread at ffff000008116e98<br /> <br /> In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,<br /> but not saved in edev-&gt;component[i].scratch<br /> <br /> In this situation, edev-&gt;component[0].scratch is an invalid pointer,<br /> when kfree it in ses_intf_remove_enclosure, a crash like above would happen<br /> The call trace also could be other random cases when kfree cannot catch<br /> the invalid pointer<br /> <br /> We should not use edev-&gt;component[] array when the components count is 0<br /> We also need check index when use edev-&gt;component[] array in<br /> ses_enclosure_data_process<br /> =====

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: net: fix use after free in fwnet_finish_incoming_packet()<br /> <br /> The netif_rx() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add vlan_get_protocol_and_depth() helper<br /> <br /> Before blamed commit, pskb_may_pull() was used instead<br /> of skb_header_pointer() in __vlan_get_protocol() and friends.<br /> <br /> Few callers depended on skb-&gt;head being populated with MAC header,<br /> syzbot caught one of them (skb_mac_gso_segment())<br /> <br /> Add vlan_get_protocol_and_depth() to make the intent clearer<br /> and use it where sensible.<br /> <br /> This is a more generic fix than commit e9d3f80935b6<br /> ("net/af_packet: make sure to pull mac header") which was<br /> dealing with a similar issue.<br /> <br /> kernel BUG at include/linux/skbuff.h:2655 !<br /> invalid opcode: 0000 [#1] SMP KASAN<br /> CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]<br /> RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136<br /> Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41<br /> RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286<br /> RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012<br /> R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7<br /> FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419<br /> [] skb_gso_segment include/linux/netdevice.h:4819 [inline]<br /> [] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725<br /> [] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313<br /> [] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029<br /> [] packet_snd net/packet/af_packet.c:3111 [inline]<br /> [] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores<br /> <br /> The IRAM is part of the HiFi DSP.<br /> According to hardware specification only 32-bits write are allowed<br /> otherwise we get a Kernel panic.<br /> <br /> Therefore add a custom memory copy and memset functions to deal with<br /> the above restriction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cassini: Fix a memory leak in the error handling path of cas_init_one()<br /> <br /> cas_saturn_firmware_init() allocates some memory using vmalloc(). This<br /> memory is freed in the .remove() function but not it the error handling<br /> path of the probe.<br /> <br /> Add the missing vfree() to avoid a memory leak, should an error occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to give up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Handle cameras with invalid descriptors<br /> <br /> If the source entity does not contain any pads, do not create a link.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE: Always save CS register on AMD Zen IF Poison errors<br /> <br /> The Instruction Fetch (IF) units on current AMD Zen-based systems do not<br /> guarantee a synchronous #MC is delivered for poison consumption errors.<br /> Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the<br /> microarchitecture does guarantee that the exception is delivered within<br /> the same context. In other words, the exact rIP is not known, but the<br /> context is known to not have changed.<br /> <br /> There is no architecturally-defined method to determine this behavior.<br /> <br /> The Code Segment (CS) register is always valid on such IF unit poison<br /> errors regardless of the value of MCG_STATUS[EIPV|RIPV].<br /> <br /> Add a quirk to save the CS register for poison consumption from the IF<br /> unit banks.<br /> <br /> This is needed to properly determine the context of the error.<br /> Otherwise, the severity grading function will assume the context is<br /> IN_KERNEL due to the m-&gt;cs value being 0 (the initialized value). This<br /> leads to unnecessary kernel panics on data poison errors due to the<br /> kernel believing the poison consumption occurred in kernel context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fw: fix memory leak in debugfs<br /> <br /> Fix a memory leak that occurs when reading the fw_info<br /> file all the way, since we return NULL indicating no<br /> more data, but don&amp;#39;t free the status tracking object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool: Fix memory leak in create_static_call_sections()<br /> <br /> strdup() allocates memory for key_name. We need to release the memory in<br /> the following error paths. Add free() to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: fix of_iomap memory leak<br /> <br /> Smatch reports:<br /> drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 496.<br /> <br /> This problem was also found in linux-next. In mtk_clk_simple_probe(),<br /> base is not released when handling errors<br /> if clk_data is not existed, which may cause a leak.<br /> So free_base should be added here to release base.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: mediatek: vpu: fix NULL ptr dereference<br /> <br /> If pdev is NULL, then it is still dereferenced.<br /> <br /> This fixes this smatch warning:<br /> <br /> drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer &amp;#39;pdev&amp;#39;