net/sctp/diag.c for instance is built into its own separate module
(sctp_diag.ko) and requires the use of sctp_endpoint_{hold,put}() in
order to prevent a recently found use-after-free issue.
In order to prevent data corruption of the pointer used to take a
reference on a specific endpoint, between the time of calling
sctp_endpoint_hold() and it returning, the API now returns a pointer
to the exact endpoint that was incremented.
For example, in sctp_sock_dump(), we could have the following hunk:
sctp_endpoint_hold(tsp->asoc->ep);
ep = tsp->asoc->ep;
sk = ep->base.sk
lock_sock(ep->base.sk);
It is possible for this task to be swapped out immediately following
the call into sctp_endpoint_hold() that would change the address of
tsp->asoc->ep to point to a completely different endpoint. This means
a reference could be taken to the old endpoint and the new one would
be processed without a reference taken, moreover the new endpoint
could then be freed whilst still processing as a result, causing a
use-after-free.
If we return the exact pointer that was held, we ensure this task
processes only the endpoint we have taken a reference to. The
resultant hunk now looks like this:
ep = sctp_endpoint_hold(tsp->asoc->ep);
sk = ep->base.sk
lock_sock(sk);
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Cc: Neil Horman <nhorman(a)tuxdriver.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Jakub Kicinski <kuba(a)kernel.org>
Cc: lksctp developers <linux-sctp(a)vger.kernel.org>
Cc: "H.P. Yarroll" <piggy(a)acm.org>
Cc: Karl Knutson <karl(a)athena.chicago.il.us>
Cc: Jon Grimm <jgrimm(a)us.ibm.com>
Cc: Xingang Guo <xingang.guo(a)intel.com>
Cc: Hui Huang <hui.huang(a)nokia.com>
Cc: Sridhar Samudrala <sri(a)us.ibm.com>
Cc: Daisy Chang <daisyc(a)us.ibm.com>
Cc: Ryan Layer <rmlayer(a)us.ibm.com>
Cc: Kevin Gao <kevin.gao(a)intel.com>
Cc: linux-sctp(a)vger.kernel.org
Cc: netdev(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
Fixes: 8f840e47f190c ("sctp: add the sctp_diag.c file")
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
---
include/net/sctp/structs.h | 2 +-
net/sctp/endpointola.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 651bba654d77d..78d71ca56452b 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1380,7 +1380,7 @@ static inline struct sctp_endpoint *sctp_ep(struct sctp_ep_common *base)
struct sctp_endpoint *sctp_endpoint_new(struct sock *, gfp_t);
void sctp_endpoint_free(struct sctp_endpoint *);
void sctp_endpoint_put(struct sctp_endpoint *);
-void sctp_endpoint_hold(struct sctp_endpoint *);
+struct sctp_endpoint *sctp_endpoint_hold(struct sctp_endpoint *);
void sctp_endpoint_add_asoc(struct sctp_endpoint *, struct sctp_association *);
struct sctp_association *sctp_endpoint_lookup_assoc(
const struct sctp_endpoint *ep,
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 48c9c2c7602f7..bdbf74fc7eb4c 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -222,10 +222,12 @@ static void sctp_endpoint_destroy(struct sctp_endpoint *ep)
}
/* Hold a reference to an endpoint. */
-void sctp_endpoint_hold(struct sctp_endpoint *ep)
+struct sctp_endpoint *sctp_endpoint_hold(struct sctp_endpoint *ep)
{
refcount_inc(&ep->base.refcnt);
+ return ep;
}
+EXPORT_SYMBOL_GPL(sctp_endpoint_hold);
/* Release a reference to an endpoint and clean up if there are
* no more references.
@@ -235,6 +237,7 @@ void sctp_endpoint_put(struct sctp_endpoint *ep)
if (refcount_dec_and_test(&ep->base.refcnt))
sctp_endpoint_destroy(ep);
}
+EXPORT_SYMBOL_GPL(sctp_endpoint_put);
/* Is this the endpoint we are looking for? */
struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *ep,
--
2.34.1.173.g76aa8bc2d0-goog
When replugging the device the following message shows up:
gpio gpiochip2: (dln2): detected irqchip that is shared with multiple gpiochips: please fix the driver.
This also has the effect that interrupts won't work.
The same problem would also show up if multiple devices where plugged in.
Fix this by allocating the irq_chip data structure per instance like other
drivers do.
I don't know when this problem appeared, but it is present in 5.10.
Cc: <stable(a)vger.kernel.org> # 5.10+
Cc: Daniel Baluta <daniel.baluta(a)gmail.com>
Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org>
---
drivers/gpio/gpio-dln2.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 4c5f6d0c8d74..22f11dd5210d 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -46,6 +46,7 @@
struct dln2_gpio {
struct platform_device *pdev;
struct gpio_chip gpio;
+ struct irq_chip irqchip;
/*
* Cache pin direction to save us one transfer, since the hardware has
@@ -383,15 +384,6 @@ static void dln2_irq_bus_unlock(struct irq_data *irqd)
mutex_unlock(&dln2->irq_lock);
}
-static struct irq_chip dln2_gpio_irqchip = {
- .name = "dln2-irq",
- .irq_mask = dln2_irq_mask,
- .irq_unmask = dln2_irq_unmask,
- .irq_set_type = dln2_irq_set_type,
- .irq_bus_lock = dln2_irq_bus_lock,
- .irq_bus_sync_unlock = dln2_irq_bus_unlock,
-};
-
static void dln2_gpio_event(struct platform_device *pdev, u16 echo,
const void *data, int len)
{
@@ -477,8 +469,15 @@ static int dln2_gpio_probe(struct platform_device *pdev)
dln2->gpio.direction_output = dln2_gpio_direction_output;
dln2->gpio.set_config = dln2_gpio_set_config;
+ dln2->irqchip.name = "dln2-irq",
+ dln2->irqchip.irq_mask = dln2_irq_mask,
+ dln2->irqchip.irq_unmask = dln2_irq_unmask,
+ dln2->irqchip.irq_set_type = dln2_irq_set_type,
+ dln2->irqchip.irq_bus_lock = dln2_irq_bus_lock,
+ dln2->irqchip.irq_bus_sync_unlock = dln2_irq_bus_unlock,
+
girq = &dln2->gpio.irq;
- girq->chip = &dln2_gpio_irqchip;
+ girq->chip = &dln2->irqchip;
/* The event comes from the outside so no parent handler */
girq->parent_handler = NULL;
girq->num_parents = 0;
--
2.33.0
Hi, this is your Linux kernel regression tracker speaking.
TWIMC, I stumbled on a bug report from George Shearer about a KVM
problem I couldn't find any further discussions about, that's why I'm
forwarding it manually here.
https://bugzilla.kernel.org/show_bug.cgi?id=215351
George, BTW: if reverting the change you suspect doesn't help, please
consider doing a bisection to find the culprit.
> KVM stopped working on two of my x86_64 systems as of version 5.15.7. Downgrading to 5.15.6 resolves all issues with no other changes.
>
> Attemping to boot kvm produces:
> kvm_set_irq: Input/output error
>
> kernel log:
> [ 1270.750295] ------------[ cut here ]------------
> [ 1270.750301] WARNING: CPU: 10 PID: 2523 at arch/x86/kvm/vmx/vmx.c:6247 vmx_sync_pir_to_irr+0x3a/0x120 [kvm_intel]
> [ 1270.750326] Modules linked in: tun bridge stp nct6775 llc hwmon_vid intel_rapl_msr intel_rapl_common iTCO_wdt intel_pmc_bxt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp intel_wmi_thunderbolt mxm_wmi coretemp kvm_intel kvm rapl intel_cstate intel_uncore raid0 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi md_mod lpc_ich snd_hda_intel i2c_i801 i2c_smbus snd_intel_dspcfg snd_intel_sdw_acpi wacom snd_usb_audio snd_hda_codec uvcvideo snd_usbmidi_lib snd_rawmidi snd_hda_core videobuf2_vmalloc snd_hwdep snd_seq_device videobuf2_memops snd_pcm mousedev nvidia_drm(POE) videobuf2_v4l2 nvidia_modeset(POE) snd_timer joydev videobuf2_common e1000e snd mei_me soundcore mei wmi v4l2loopback(OE) videodev mc nvidia_uvm(POE) nvidia(POE) mac_hid crypto_user fuse ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core usbhid dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_i
ntel
> [ 1270.750432] aesni_intel crypto_simd cryptd sr_mod xhci_pci cdrom xhci_pci_renesas vfio_pci vfio_pci_core irqbypass vfio_virqfd vfio_iommu_type1 vfio vfat fat nls_iso8859_1
> [ 1270.750454] CPU: 10 PID: 2523 Comm: qemu-system-x86 Tainted: P OE 5.15.10-arch1-1 #1 bbe3990b16b2d76240a936ebf8dc5ba666258542
> [ 1270.750460] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X99 Extreme4, BIOS P3.80 04/06/2018
> [ 1270.750463] RIP: 0010:vmx_sync_pir_to_irr+0x3a/0x120 [kvm_intel]
> [ 1270.750478] Code: 04 25 28 00 00 00 48 89 44 24 08 31 c0 80 3d fc fb 09 ff 00 c7 44 24 04 00 00 00 00 75 47 48 8b 07 80 b8 04 c2 00 00 00 75 16 <0f> 0b 48 8b 3f be 04 03 00 00 c6 87 04 c2 00 00 01 e8 d0 71 fe fe
> [ 1270.750481] RSP: 0018:ffffb57a43b6b9e0 EFLAGS: 00010246
> [ 1270.750485] RAX: ffffb57a43f45000 RBX: ffffa03e3283c000 RCX: 0000000000000000
> [ 1270.750488] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffa03e3283c000
> [ 1270.750491] RBP: ffffa03dca000000 R08: 0000000000000000 R09: 0000000000000000
> [ 1270.750493] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb57a43b6bb40
> [ 1270.750495] R13: ffffb57a43b6bb88 R14: 00007f9199ddb120 R15: ffffa03e3283c000
> [ 1270.750499] FS: 00007f9199ddc640(0000) GS:ffffa05cdfc80000(0000) knlGS:0000000000000000
> [ 1270.750502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1270.750505] CR2: 000056523dccf000 CR3: 0000000105e84006 CR4: 00000000003726e0
> [ 1270.750508] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1270.750511] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1270.750513] Call Trace:
> [ 1270.750517] <TASK>
> [ 1270.750521] kvm_arch_vcpu_ioctl+0xcd6/0x1560 [kvm 97b295b32edb47f6953359c3801fec0571c9fadd]
> [ 1270.750631] kvm_vcpu_ioctl+0x42e/0x6e0 [kvm 97b295b32edb47f6953359c3801fec0571c9fadd]
> [ 1270.750694] ? syscall_exit_to_user_mode+0x23/0x50
> [ 1270.750702] ? __fget_files+0x9c/0xd0
> [ 1270.750712] __x64_sys_ioctl+0x8b/0xd0
> [ 1270.750717] do_syscall_64+0x59/0x90
> [ 1270.750721] ? syscall_exit_to_user_mode+0x23/0x50
> [ 1270.750727] ? do_syscall_64+0x69/0x90
> [ 1270.750730] ? do_syscall_64+0x69/0x90
> [ 1270.750733] ? do_syscall_64+0x69/0x90
> [ 1270.750736] entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 1270.750744] RIP: 0033:0x7f919d2b859b
> [ 1270.750748] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
> [ 1270.750751] RSP: 002b:00007f9199ddb078 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 1270.750756] RAX: ffffffffffffffda RBX: 000000008400ae8e RCX: 00007f919d2b859b
> [ 1270.750759] RDX: 00007f9199ddb120 RSI: ffffffff8400ae8e RDI: 0000000000000019
> [ 1270.750782] RBP: 000056523db2db60 R08: 000056523cb2eac4 R09: 000056523cb2ea24
> [ 1270.750785] R10: 000056523cb2e8c0 R11: 0000000000000246 R12: 00007f9199ddb120
> [ 1270.750787] R13: 000000aa00000000 R14: 0000005500000000 R15: 000fff0000000000
> [ 1270.750793] </TASK>
> [ 1270.750795] ---[ end trace e0f3b79e15ad0008 ]---
>
> $ cat /proc/cmdline
> quiet splash vga=current nomodeset loglevel=0 rd.systemd.show_status=false rd.udev.log_priority=0 intremap=no_x2apic_optout mitigations=off root=/dev/vg00/root rw rootfstype=ext4 add_efi_memmap initrd=EFI\arch\intel-ucode.img initrd=EFI\arch\initramfs.img init=/usr/lib/systemd/systemd intel_iommu=on iommu=pt rd.luks.uuid=f863c926-fd06-4135-841b-a825f6aacb25 rd.luks.options=discard
>
> $ cat /etc/modprobe.d/kvm.conf
> options kvm ignore_msrs=1
> options kvm-intel nested=y ept=y enable_apicv=n
>
> NOTE-- if I change that enable_apicv to 'y' -- my kvm instance boots but hangs when attempting to access SRV-IO PCI-E GPU.
>
> $ grep 'model name' /proc/cpuinfo |head -1; uname -a
> model name : Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz
> Linux docslinuxbox 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37 +0000 x86_64 GNU/Linux
>
> $ free
> total used free shared buff/cache available
> Mem: 132031320 19011304 110854572 110980 2165444 110007200
> Swap: 16777212 0 16777212
> I believe this problem has something to do with this work:
>
> https://www.spinics.net/lists/stable/msg519358.html
> (In reply to Thorsten Leemhuis from comment #3)
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> 5.15.10 is out and contains a fix for a KVM issue. Could you give it a try?
>> If not, we should bring the report to the mailing lists, as outlined in
>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>
>> And btw: have you tried to revert the change you pointed to above to see if
>> it fixes the problem?
>
> Yes, the problem persist in 5.15.10, here's a fresh cut/paste:
>
> [ 137.123571] ------------[ cut here ]------------
> [ 137.123575] WARNING: CPU: 1 PID: 3606 at arch/x86/kvm/vmx/vmx.c:6247 vmx_sync_pir_to_irr+0x3a/0x120 [kvm_intel]
> [ 137.123587] Modules linked in: tun rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache netfs intel_rapl_msr intel_rapl_common bridge stp nct6775 llc hwmon_vid iTCO_wdt intel_pmc_bxt iTCO_vendor_support x86_pkg_temp_thermal intel_wmi_thunderbolt mxm_wmi intel_powerclamp coretemp kvm_intel kvm rapl intel_cstate snd_hda_codec_realtek intel_uncore raid0 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio md_mod snd_hda_intel i2c_i801 snd_intel_dspcfg lpc_ich i2c_smbus e1000e snd_intel_sdw_acpi snd_usb_audio snd_hda_codec wacom snd_hda_core uvcvideo snd_usbmidi_lib videobuf2_vmalloc videobuf2_memops snd_rawmidi snd_hwdep nvidia_drm(POE) videobuf2_v4l2 snd_seq_device mousedev nvidia_modeset(POE) joydev videobuf2_common snd_pcm snd_timer snd mei_me soundcore mei wmi v4l2loopback(OE) videodev mc nvidia_uvm(POE) nvidia(POE) mac_hid crypto_user fuse ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys trusted asn1_encoder tee t
pm
> [ 137.123628] rng_core usbhid dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd sr_mod xhci_pci cdrom xhci_pci_renesas vfio_pci vfio_pci_core irqbypass vfio_virqfd vfio_iommu_type1 vfio vfat fat nls_iso8859_1
> [ 137.123639] CPU: 1 PID: 3606 Comm: qemu-system-x86 Tainted: P OE 5.15.10-arch1-1 #1 bbe3990b16b2d76240a936ebf8dc5ba666258542
> [ 137.123642] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X99 Extreme4, BIOS P3.80 04/06/2018
> [ 137.123643] RIP: 0010:vmx_sync_pir_to_irr+0x3a/0x120 [kvm_intel]
> [ 137.123648] Code: 04 25 28 00 00 00 48 89 44 24 08 31 c0 80 3d fc 4b 15 00 00 c7 44 24 04 00 00 00 00 75 47 48 8b 07 80 b8 04 c2 00 00 00 75 16 <0f> 0b 48 8b 3f be 04 03 00 00 c6 87 04 c2 00 00 01 e8 d0 c1 09 00
> [ 137.123649] RSP: 0018:ffffbb63c3cbf978 EFLAGS: 00010246
> [ 137.123650] RAX: ffffbb63c3d21000 RBX: ffff9597a7258000 RCX: 0000000000000000
> [ 137.123651] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9597a7258000
> [ 137.123652] RBP: ffff95970f04ec00 R08: 0000000000000000 R09: 0000000000000000
> [ 137.123653] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbb63c3cbfad8
> [ 137.123654] R13: ffffbb63c3cbfb20 R14: 00007f4742c99120 R15: ffff9597a7258000
> [ 137.123655] FS: 00007f4742c9a640(0000) GS:ffff95b61fa40000(0000) knlGS:0000000000000000
> [ 137.123656] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 137.123657] CR2: 00007fd7827d0000 CR3: 0000000122638002 CR4: 00000000003726e0
> [ 137.123658] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 137.123659] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 137.123659] Call Trace:
> [ 137.123661] <TASK>
> [ 137.123663] kvm_arch_vcpu_ioctl+0xcd6/0x1560 [kvm 97b295b32edb47f6953359c3801fec0571c9fadd]
> [ 137.123712] kvm_vcpu_ioctl+0x42e/0x6e0 [kvm 97b295b32edb47f6953359c3801fec0571c9fadd]
> [ 137.123732] ? syscall_exit_to_user_mode+0x23/0x50
> [ 137.123736] ? __fget_files+0x9c/0xd0
> [ 137.123741] __x64_sys_ioctl+0x8b/0xd0
> [ 137.123743] do_syscall_64+0x59/0x90
> [ 137.123744] ? syscall_exit_to_user_mode+0x23/0x50
> [ 137.123746] ? do_syscall_64+0x69/0x90
> [ 137.123747] ? syscall_exit_to_user_mode+0x23/0x50
> [ 137.123749] ? do_syscall_64+0x69/0x90
> [ 137.123750] ? syscall_exit_to_user_mode+0x23/0x50
> [ 137.123751] ? do_syscall_64+0x69/0x90
> [ 137.123752] entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 137.123755] RIP: 0033:0x7f474a17959b
> [ 137.123757] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
> [ 137.123758] RSP: 002b:00007f4742c99078 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 137.123759] RAX: ffffffffffffffda RBX: 000000008400ae8e RCX: 00007f474a17959b
> [ 137.123760] RDX: 00007f4742c99120 RSI: ffffffff8400ae8e RDI: 0000000000000019
> [ 137.123761] RBP: 0000561c10142b60 R08: 0000561c0dbe5ac4 R09: 0000561c0dbe5a24
> [ 137.123762] R10: 0000561c0dbe58c0 R11: 0000000000000246 R12: 00007f4742c99120
> [ 137.123762] R13: 000000aa00000000 R14: 0000005500000000 R15: 000fff0000000000
> [ 137.123765] </TASK>
> [ 137.123765] ---[ end trace 356a4adaddf3d772 ]---
>
>
> I haven't had time to try to revert the change as these are both production systems and will require downtime. Maybe Sunday.
[TLDR: I'm adding this regression to regzbot, the Linux kernel
regression tracking bot; most text you find below is compiled from a few
templates paragraphs some of you might have seen already.]
To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot introduced v5.15.6..v5.15.7
#regzbot title Kernel OOPS in vmx.c when starting a kvm VM
#regzbot ignore-activity
Reminder: when fixing the issue, please add a 'Link:' tag with the URL
to the report (the parent of this mail) using the kernel.org redirector,
as explained in 'Documentation/process/submitting-patches.rst'. Regzbot
then will automatically mark the regression as resolved once the fix
lands in the appropriate tree. For more details about regzbot see footer.
Sending this to everyone that got the initial report, to make all aware
of the tracking. I also hope that messages like this motivate people to
directly get at least the regression mailing list and ideally even
regzbot involved when dealing with regressions, as messages like this
wouldn't be needed then.
Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), as
long as they are intended just for regzbot. With a bit of luck no such
messages will be needed anyway.
Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat).
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave thus might sent someone reading this down the wrong
rabbit hole, which none of us wants.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
---
Additional information about regzbot:
If you want to know more about regzbot, check out its web-interface, the
getting start guide, and/or the references documentation:
https://linux-regtracking.leemhuis.info/regzbot/https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.mdhttps://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
The last two documents will explain how you can interact with regzbot
yourself if your want to.
Hint for reporters: when reporting a regression it's in your interest to
tell #regzbot about it in the report, as that will ensure the regression
gets on the radar of regzbot and the regression tracker. That's in your
interest, as they will make sure the report won't fall through the
cracks unnoticed.
Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include a 'Link:' tag to the report in the commit message, as explained
in Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: aa1701e20a847dba6c406545dcba6a8755fa6406
Gitweb: https://git.kernel.org/tip/aa1701e20a847dba6c406545dcba6a8755fa6406
Author: Andrew Cooper <andrew.cooper3(a)citrix.com>
AuthorDate: Thu, 16 Dec 2021 00:08:56
Committer: Borislav Petkov <bp(a)suse.de>
CommitterDate: Sun, 19 Dec 2021 14:09:41 +01:00
x86/pkey: Fix undefined behaviour with PKRU_WD_BIT
Both __pkru_allows_write() and arch_set_user_pkey_access() shift
PKRU_WD_BIT (a signed constant) by up to 30 bits, hitting the
sign bit.
Use unsigned constants instead.
Clearly pkey 15 has not been used in combination with UBSAN yet.
Noticed by code inspection only. I can't actually provoke the
compiler into generating incorrect logic as far as this shift is
concerned.
[
dhansen: add stable@ tag, plus minor changelog massaging,
For anyone doing backports, these #defines were in
arch/x86/include/asm/pgtable.h before 784a46618f6.
]
Fixes: 33a709b25a76 ("mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys")
Signed-off-by: Andrew Cooper <andrew.cooper3(a)citrix.com>
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20211216000856.4480-1-andrew.cooper3@citrix.com
---
arch/x86/include/asm/pkru.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkru.h b/arch/x86/include/asm/pkru.h
index 4cd49af..74f0a2d 100644
--- a/arch/x86/include/asm/pkru.h
+++ b/arch/x86/include/asm/pkru.h
@@ -4,8 +4,8 @@
#include <asm/cpufeature.h>
-#define PKRU_AD_BIT 0x1
-#define PKRU_WD_BIT 0x2
+#define PKRU_AD_BIT 0x1u
+#define PKRU_WD_BIT 0x2u
#define PKRU_BITS_PER_PKEY 2
#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS