Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix crash in auto_retire<br /> <br /> The retire logic uses the 2 lower bits of the pointer to the retire<br /> function to store flags. However, the auto_retire function is not<br /> guaranteed to be aligned to a multiple of 4, which causes crashes as<br /> we jump to the wrong address, for example like this:<br /> <br /> 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1<br /> 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021<br /> 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work<br /> 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20<br /> 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74<br /> 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286<br /> 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007<br /> 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600<br /> 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff<br /> 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0<br /> 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605<br /> 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000<br /> 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0<br /> 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554<br /> 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace:<br /> 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf<br /> 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394<br /> 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375<br /> 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156<br /> 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58<br /> 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e<br /> 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40<br /> 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Disable preemption when probing user return MSRs<br /> <br /> Disable preemption when probing a user return MSR via RDSMR/WRMSR. If<br /> the MSR holds a different value per logical CPU, the WRMSR could corrupt<br /> the host&amp;#39;s value if KVM is preempted between the RDMSR and WRMSR, and<br /> then rescheduled on a different CPU.<br /> <br /> Opportunistically land the helper in common x86, SVM will use the helper<br /> in a future commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nVMX: Always make an attempt to map eVMCS after migration<br /> <br /> When enlightened VMCS is in use and nested state is migrated with<br /> vmx_get_nested_state()/vmx_set_nested_state() KVM can&amp;#39;t map evmcs<br /> page right away: evmcs gpa is not &amp;#39;struct kvm_vmx_nested_state_hdr&amp;#39;<br /> and we can&amp;#39;t read it from VP assist page because userspace may decide<br /> to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state<br /> (and QEMU, for example, does exactly that). To make sure eVMCS is<br /> mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES<br /> request.<br /> <br /> Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES<br /> on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to<br /> nested_vmx_vmexit() to make sure MSR permission bitmap is not switched<br /> when an immediate exit from L2 to L1 happens right after migration (caused<br /> by a pending event, for example). Unfortunately, in the exact same<br /> situation we still need to have eVMCS mapped so<br /> nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.<br /> <br /> As a band-aid, restore nested_get_evmcs_page() when clearing<br /> KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The &amp;#39;fix&amp;#39; is far<br /> from being ideal as we can&amp;#39;t easily propagate possible failures and even if<br /> we could, this is most likely already too late to do so. The whole<br /> &amp;#39;KVM_REQ_GET_NESTED_STATE_PAGES&amp;#39; idea for mapping eVMCS after migration<br /> seems to be fragile as we diverge too much from the &amp;#39;native&amp;#39; path when<br /> vmptr loading happens on vmx_set_nested_state().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: fix ioctl handlers removal<br /> <br /> Currently ioctl handlers are removed twice. For the first time during<br /> iio_device_unregister() then later on inside<br /> iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask().<br /> Double free leads to kernel panic.<br /> <br /> Fix this by not touching ioctl handlers list directly but rather<br /> letting code responsible for registration call the matching cleanup<br /> routine itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4<br /> <br /> commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects<br /> in PD mode") introduced retrieval of the PDOs when connected to a<br /> PD-capable source. But only the first 4 PDOs are received since<br /> that is the maximum number that can be fetched at a time given the<br /> MESSAGE_IN length limitation (16 bytes). However, as per the PD spec<br /> a connected source may advertise up to a maximum of 7 PDOs.<br /> <br /> If such a source is connected it&amp;#39;s possible the PPM could have<br /> negotiated a power contract with one of the PDOs at index greater<br /> than 4, and would be reflected in the request data object&amp;#39;s (RDO)<br /> object position field. This would result in an out-of-bounds access<br /> when the rdo_index() is used to index into the src_pdos array in<br /> ucsi_psy_get_voltage_now().<br /> <br /> With the help of the UBSAN -fsanitize=array-bounds checker enabled<br /> this exact issue is revealed when connecting to a PD source adapter<br /> that advertise 5 PDOs and the PPM enters a contract having selected<br /> the 5th one.<br /> <br /> [ 151.545106][ T70] Unexpected kernel BRK exception at EL1<br /> [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP<br /> ...<br /> [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c<br /> [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328<br /> ...<br /> [ 151.545542][ T70] Call trace:<br /> [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c<br /> [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0<br /> [ 151.545550][ T70] dev_uevent+0x200/0x384<br /> [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8<br /> [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c<br /> [ 151.545562][ T70] process_one_work+0x244/0x6f0<br /> [ 151.545564][ T70] worker_thread+0x3e0/0xa64<br /> <br /> We can resolve this by instead retrieving and storing up to the<br /> maximum of 7 PDOs in the con-&gt;src_pdos array. This would involve<br /> two calls to the GET_PDOS command.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: Fix NULL pointer in flush_workqueue<br /> <br /> Open /dev/nbdX first, the config_refs will be 1 and<br /> the pointers in nbd_device are still null. Disconnect<br /> /dev/nbdX, then reference a null recv_workq. The<br /> protection by config_refs in nbd_genl_disconnect is useless.<br /> <br /> [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> [ 656.368943] #PF: supervisor write access in kernel mode<br /> [ 656.369844] #PF: error_code(0x0002) - not-present page<br /> [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0<br /> [ 656.371693] Oops: 0002 [#1] SMP<br /> [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1<br /> [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014<br /> [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60<br /> [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d<br /> [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246<br /> [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020<br /> [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318<br /> [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40<br /> [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00<br /> [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000<br /> [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0<br /> [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 656.384927] Call Trace:<br /> [ 656.385111] flush_workqueue+0x92/0x6c0<br /> [ 656.385395] nbd_disconnect_and_put+0x81/0xd0<br /> [ 656.385716] nbd_genl_disconnect+0x125/0x2a0<br /> [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0<br /> [ 656.386422] genl_rcv_msg+0xfc/0x2b0<br /> [ 656.386685] ? nbd_ioctl+0x490/0x490<br /> [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0<br /> [ 656.387354] netlink_rcv_skb+0x62/0x180<br /> [ 656.387638] genl_rcv+0x34/0x60<br /> [ 656.387874] netlink_unicast+0x26d/0x590<br /> [ 656.388162] netlink_sendmsg+0x398/0x6c0<br /> [ 656.388451] ? netlink_rcv_skb+0x180/0x180<br /> [ 656.388750] ____sys_sendmsg+0x1da/0x320<br /> [ 656.389038] ? ____sys_recvmsg+0x130/0x220<br /> [ 656.389334] ___sys_sendmsg+0x8e/0xf0<br /> [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0<br /> [ 656.389889] ? handle_mm_fault+0x1671/0x21d0<br /> [ 656.390201] __sys_sendmsg+0x6d/0xe0<br /> [ 656.390464] __x64_sys_sendmsg+0x23/0x30<br /> [ 656.390751] do_syscall_64+0x45/0x70<br /> [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> To fix it, just add if (nbd-&gt;recv_workq) to nbd_disconnect_and_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix race condition of overwrite vs truncate<br /> <br /> pos_fsstress testcase complains a panic as belew:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/compress.c:1082!<br /> invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Workqueue: writeback wb_workfn (flush-252:16)<br /> RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs]<br /> Call Trace:<br /> f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs]<br /> f2fs_write_cache_pages+0x468/0x8a0 [f2fs]<br /> f2fs_write_data_pages+0x2a4/0x2f0 [f2fs]<br /> do_writepages+0x38/0xc0<br /> __writeback_single_inode+0x44/0x2a0<br /> writeback_sb_inodes+0x223/0x4d0<br /> __writeback_inodes_wb+0x56/0xf0<br /> wb_writeback+0x1dd/0x290<br /> wb_workfn+0x309/0x500<br /> process_one_work+0x220/0x3c0<br /> worker_thread+0x53/0x420<br /> kthread+0x12f/0x150<br /> ret_from_fork+0x22/0x30<br /> <br /> The root cause is truncate() may race with overwrite as below,<br /> so that one reference count left in page can not guarantee the<br /> page attaching in mapping tree all the time, after truncation,<br /> later find_lock_page() may return NULL pointer.<br /> <br /> - prepare_compress_overwrite<br /> - f2fs_pagecache_get_page<br /> - unlock_page<br /> - f2fs_setattr<br /> - truncate_setsize<br /> - truncate_inode_page<br /> - delete_from_page_cache<br /> - find_lock_page<br /> <br /> Fix this by avoiding referencing updated page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-rdma: Fix NULL deref when SEND is completed with error<br /> <br /> When running some traffic and taking down the link on peer, a<br /> retry counter exceeded error is received. This leads to<br /> nvmet_rdma_error_comp which tried accessing the cq_context to<br /> obtain the queue. The cq_context is no longer valid after the<br /> fix to use shared CQ mechanism and should be obtained similar<br /> to how it is obtained in other functions from the wc-&gt;qp.<br /> <br /> [ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12).<br /> [ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048<br /> [ 905.839919] PGD 0 P4D 0<br /> [ 905.842464] Oops: 0000 1 SMP NOPTI<br /> [ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1<br /> [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma]<br /> [ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff<br /> [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246<br /> [ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000<br /> [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000<br /> [ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074<br /> [ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010<br /> [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400<br /> [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000<br /> [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12).<br /> [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0<br /> [ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 905.961857] PKRU: 55555554<br /> [ 906.010315] Call Trace:<br /> [ 906.012778] __ib_process_cq+0x89/0x170 [ib_core]<br /> [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core]<br /> [ 906.022152] process_one_work+0x1a7/0x360<br /> [ 906.026182] ? create_worker+0x1a0/0x1a0<br /> [ 906.030123] worker_thread+0x30/0x390<br /> [ 906.033802] ? create_worker+0x1a0/0x1a0<br /> [ 906.037744] kthread+0x116/0x130<br /> [ 906.040988] ? kthread_flush_work_fn+0x10/0x10<br /> [ 906.045456] ret_from_fork+0x1f/0x40

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kyber: fix out of bounds access when preempted<br /> <br /> __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and<br /> passes the hctx to -&gt;bio_merge(). kyber_bio_merge() then gets the ctx<br /> for the current CPU again and uses that to get the corresponding Kyber<br /> context in the passed hctx. However, the thread may be preempted between<br /> the two calls to blk_mq_get_ctx(), and the ctx returned the second time<br /> may no longer correspond to the passed hctx. This "works" accidentally<br /> most of the time, but it can cause us to read garbage if the second ctx<br /> came from an hctx with more ctx&amp;#39;s than the first one (i.e., if<br /> ctx-&gt;index_hw[hctx-&gt;type] &gt; hctx-&gt;nr_ctx).<br /> <br /> This manifested as this UBSAN array index out of bounds error reported<br /> by Jakub:<br /> <br /> UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9<br /> index 13106 is out of range for type &amp;#39;long unsigned int [128]&amp;#39;<br /> Call Trace:<br /> dump_stack+0xa4/0xe5<br /> ubsan_epilogue+0x5/0x40<br /> __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34<br /> queued_spin_lock_slowpath+0x476/0x480<br /> do_raw_spin_lock+0x1c2/0x1d0<br /> kyber_bio_merge+0x112/0x180<br /> blk_mq_submit_bio+0x1f5/0x1100<br /> submit_bio_noacct+0x7b0/0x870<br /> submit_bio+0xc2/0x3a0<br /> btrfs_map_bio+0x4f0/0x9d0<br /> btrfs_submit_data_bio+0x24e/0x310<br /> submit_one_bio+0x7f/0xb0<br /> submit_extent_page+0xc4/0x440<br /> __extent_writepage_io+0x2b8/0x5e0<br /> __extent_writepage+0x28d/0x6e0<br /> extent_write_cache_pages+0x4d7/0x7a0<br /> extent_writepages+0xa2/0x110<br /> do_writepages+0x8f/0x180<br /> __writeback_single_inode+0x99/0x7f0<br /> writeback_sb_inodes+0x34e/0x790<br /> __writeback_inodes_wb+0x9e/0x120<br /> wb_writeback+0x4d2/0x660<br /> wb_workfn+0x64d/0xa10<br /> process_one_work+0x53a/0xa80<br /> worker_thread+0x69/0x5b0<br /> kthread+0x20b/0x240<br /> ret_from_fork+0x1f/0x30<br /> <br /> Only Kyber uses the hctx, so fix it by passing the request_queue to<br /> -&gt;bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can<br /> map the queues itself to avoid the mismatch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: scan: Fix a memory leak in an error handling path<br /> <br /> If &amp;#39;acpi_device_set_name()&amp;#39; fails, we must free<br /> &amp;#39;acpi_device_bus_id-&gt;bus_id&amp;#39; or there is a (potential) memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Free gadget structure only after freeing endpoints<br /> <br /> As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure<br /> dynamically") the dwc3_gadget_release() was added which will free<br /> the dwc-&gt;gadget structure upon the device&amp;#39;s removal when<br /> usb_del_gadget_udc() is called in dwc3_gadget_exit().<br /> <br /> However, simply freeing the gadget results a dangling pointer<br /> situation: the endpoints created in dwc3_gadget_init_endpoints()<br /> have their dep-&gt;endpoint.ep_list members chained off the list_head<br /> anchored at dwc-&gt;gadget-&gt;ep_list. Thus when dwc-&gt;gadget is freed,<br /> the first dwc3_ep in the list now has a dangling prev pointer and<br /> likewise for the next pointer of the dwc3_ep at the tail of the list.<br /> The dwc3_gadget_free_endpoints() that follows will result in a<br /> use-after-free when it calls list_del().<br /> <br /> This was caught by enabling KASAN and performing a driver unbind.<br /> The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown<br /> callback for dwc3") also exposes this as a panic during shutdown.<br /> <br /> There are a few possibilities to fix this. One could be to perform<br /> a list_del() of the gadget-&gt;ep_list itself which removes it from<br /> the rest of the dwc3_ep chain.<br /> <br /> Another approach is what this patch does, by splitting up the<br /> usb_del_gadget_udc() call into its separate "del" and "put"<br /> components. This allows dwc3_gadget_free_endpoints() to be<br /> called before the gadget is finally freed with usb_put_gadget().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: release page in error path to avoid BUG_ON<br /> <br /> Consider the following sequence of events:<br /> <br /> 1. Userspace issues a UFFD ioctl, which ends up calling into<br /> shmem_mfill_atomic_pte(). We successfully account the blocks, we<br /> shmem_alloc_page(), but then the copy_from_user() fails. We return<br /> -ENOENT. We don&amp;#39;t release the page we allocated.<br /> 2. Our caller detects this error code, tries the copy_from_user() after<br /> dropping the mmap_lock, and retries, calling back into<br /> shmem_mfill_atomic_pte().<br /> 3. Meanwhile, let&amp;#39;s say another process filled up the tmpfs being used.<br /> 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and<br /> immediately returns - without releasing the page.<br /> <br /> This triggers a BUG_ON in our caller, which asserts that the page<br /> should always be consumed, unless -ENOENT is returned.<br /> <br /> To fix this, detect if we have such a "dangling" page when accounting<br /> fails, and if so, release it before returning.