- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 3778/10596] drivers/video/fbdev/ls2k500sfb.c:322:49: sparse: sparse: incorrect type in argument 2 (different address spaces)
by kernel test robot 08 Jul '24

08 Jul '24

Hi Xianglai, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3b421b6002e287e38790cbdad4a3e08baf7e1bc4 commit: 351aa968603500987e891b20cc97a677602ae7c2 [3778/10596] loongarch/kernel: Fix loongarch compilation error config: loongarch-randconfig-r132-20240707 (https://download.01.org/0day-ci/archive/20240708/202407080311.6JOR7V5E-lkp@…) compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240708/202407080311.6JOR7V5E-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202407080311.6JOR7V5E-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/video/fbdev/ls2k500sfb.c:144:27: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *static p @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:144:27: sparse: expected void *static p drivers/video/fbdev/ls2k500sfb.c:144:27: sparse: got void [noderef] __iomem * drivers/video/fbdev/ls2k500sfb.c:146:30: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void *static p @@ drivers/video/fbdev/ls2k500sfb.c:146:30: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:146:30: sparse: got void *static p drivers/video/fbdev/ls2k500sfb.c:201:36: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *static p @@ drivers/video/fbdev/ls2k500sfb.c:201:36: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:201:36: sparse: got void *static p drivers/video/fbdev/ls2k500sfb.c:203:37: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:203:37: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:203:37: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:256:13: sparse: sparse: symbol 'ls2k500sfb_interrupt' was not declared. Should it be static? drivers/video/fbdev/ls2k500sfb.c:322:22: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:322:22: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:322:22: sparse: got void * >> drivers/video/fbdev/ls2k500sfb.c:322:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:322:49: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:322:49: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:323:22: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:323:22: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:323:22: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:323:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:323:53: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:323:53: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:324:22: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:324:22: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:324:22: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:324:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:324:53: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:324:53: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:325:22: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:325:22: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:325:22: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:325:51: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:325:51: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:325:51: sparse: got void * drivers/video/fbdev/ls2k500sfb.c:458:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got char *preg @@ drivers/video/fbdev/ls2k500sfb.c:458:28: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:458:28: sparse: got char *preg drivers/video/fbdev/ls2k500sfb.c:459:32: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got char *preg @@ drivers/video/fbdev/ls2k500sfb.c:459:32: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:459:32: sparse: got char *preg drivers/video/fbdev/ls2k500sfb.c:571:19: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *penv @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:571:19: sparse: expected char *penv drivers/video/fbdev/ls2k500sfb.c:571:19: sparse: got void [noderef] __iomem * drivers/video/fbdev/ls2k500sfb.c:572:19: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *preg @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:572:19: sparse: expected char *preg drivers/video/fbdev/ls2k500sfb.c:572:19: sparse: got void [noderef] __iomem * drivers/video/fbdev/ls2k500sfb.c:674:14: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *penv @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:674:14: sparse: expected char *penv drivers/video/fbdev/ls2k500sfb.c:674:14: sparse: got void [noderef] __iomem * vim +322 drivers/video/fbdev/ls2k500sfb.c 8248d42b7c5f433 Chong Qiao 2023-12-11 113 4fbeaa84ef36adc Chong Qiao 2023-12-11 114 static unsigned long event_jiffies; 8248d42b7c5f433 Chong Qiao 2023-12-11 115 static void ls2k500sfb_events_fn(struct work_struct *work) 8248d42b7c5f433 Chong Qiao 2023-12-11 116 { 8248d42b7c5f433 Chong Qiao 2023-12-11 117 struct ls2k500sfb_struct *priv = container_of(work, struct ls2k500sfb_struct, work); 8248d42b7c5f433 Chong Qiao 2023-12-11 118 struct pci_dev *pdev = priv->dev; 8248d42b7c5f433 Chong Qiao 2023-12-11 119 struct pci_dev *ppdev = pdev->bus->self; 8248d42b7c5f433 Chong Qiao 2023-12-11 120 uint32_t i, d, timeout, retry = 0; 8248d42b7c5f433 Chong Qiao 2023-12-11 121 static const uint32_t index[] = { 8248d42b7c5f433 Chong Qiao 2023-12-11 122 0x10, 0x14, 0x18, 0x1c, 0x20, 0x24, 0x30, 0x3c, 0x54, 0x58, 0x78, 0x7c, 0x80, 4 8248d42b7c5f433 Chong Qiao 2023-12-11 123 }; 8248d42b7c5f433 Chong Qiao 2023-12-11 124 8248d42b7c5f433 Chong Qiao 2023-12-11 125 static uint32_t data[sizeof(index) / 4]; 8248d42b7c5f433 Chong Qiao 2023-12-11 126 static const uint32_t cindex[] = { 0x10, 0x3c, 4 }; 8248d42b7c5f433 Chong Qiao 2023-12-11 127 8248d42b7c5f433 Chong Qiao 2023-12-11 128 static uint32_t cdata[sizeof(cindex) / 4]; 8248d42b7c5f433 Chong Qiao 2023-12-11 129 static uint32_t d80c, d71c, ctrl; 8248d42b7c5f433 Chong Qiao 2023-12-11 130 static void *p; 8248d42b7c5f433 Chong Qiao 2023-12-11 131 8248d42b7c5f433 Chong Qiao 2023-12-11 132 if (!priv->running) { 8248d42b7c5f433 Chong Qiao 2023-12-11 133 for (i = 0; i < ARRAY_SIZE(index); i++) 8248d42b7c5f433 Chong Qiao 2023-12-11 134 pci_read_config_dword(ppdev, index[i], &data[i]); 8248d42b7c5f433 Chong Qiao 2023-12-11 135 for (i = 0; i < ARRAY_SIZE(cindex); i++) 8248d42b7c5f433 Chong Qiao 2023-12-11 136 pci_read_config_dword(pdev, cindex[i], &cdata[i]); 8248d42b7c5f433 Chong Qiao 2023-12-11 137 if (ppdev->vendor == 0x14) { 8248d42b7c5f433 Chong Qiao 2023-12-11 138 pci_read_config_dword(ppdev, 0x80c, &d80c); 8248d42b7c5f433 Chong Qiao 2023-12-11 139 d80c = (d80c & ~(3 << 17)) | (1 << 17); 8248d42b7c5f433 Chong Qiao 2023-12-11 140 8248d42b7c5f433 Chong Qiao 2023-12-11 141 pci_read_config_dword(ppdev, 0x71c, &d71c); 8248d42b7c5f433 Chong Qiao 2023-12-11 142 d71c |= 1 << 26; 8248d42b7c5f433 Chong Qiao 2023-12-11 143 8248d42b7c5f433 Chong Qiao 2023-12-11 144 p = pci_iomap(ppdev, 0, 0x100); 8248d42b7c5f433 Chong Qiao 2023-12-11 145 } 8248d42b7c5f433 Chong Qiao 2023-12-11 146 ctrl = readl(p); 8248d42b7c5f433 Chong Qiao 2023-12-11 147 return; 8248d42b7c5f433 Chong Qiao 2023-12-11 148 } 8248d42b7c5f433 Chong Qiao 2023-12-11 149 local_bh_disable(); 8248d42b7c5f433 Chong Qiao 2023-12-11 150 pciebreak_smp_send_stop(100); 8248d42b7c5f433 Chong Qiao 2023-12-11 151 wmb(); /* flush all write before we disable pcie window */ 8248d42b7c5f433 Chong Qiao 2023-12-11 152 pci_write_config_dword(ppdev, 0x18, 0); 8248d42b7c5f433 Chong Qiao 2023-12-11 153 pci_write_config_dword(ppdev, 0x1c, 0); 8248d42b7c5f433 Chong Qiao 2023-12-11 154 pci_write_config_dword(ppdev, 0x20, 0); 4fbeaa84ef36adc Chong Qiao 2023-12-11 155 event_jiffies = jiffies; 8248d42b7c5f433 Chong Qiao 2023-12-11 156 atomic_set(&waiting_for_pciebreak_ipi, 0); 8248d42b7c5f433 Chong Qiao 2023-12-11 157 wmb(); /* flush all write after change pcie window */ 8248d42b7c5f433 Chong Qiao 2023-12-11 158 local_bh_enable(); 8248d42b7c5f433 Chong Qiao 2023-12-11 159 if (ppdev->vendor == 0x14) { 8248d42b7c5f433 Chong Qiao 2023-12-11 160 timeout = 10000; 8248d42b7c5f433 Chong Qiao 2023-12-11 161 while (timeout) { 8248d42b7c5f433 Chong Qiao 2023-12-11 162 pci_read_config_dword(ppdev, 0x10, &d); 8248d42b7c5f433 Chong Qiao 2023-12-11 163 d &= ~0xf; 8248d42b7c5f433 Chong Qiao 2023-12-11 164 if (!d) 8248d42b7c5f433 Chong Qiao 2023-12-11 165 break; 8248d42b7c5f433 Chong Qiao 2023-12-11 166 mdelay(1); 8248d42b7c5f433 Chong Qiao 2023-12-11 167 timeout--; 8248d42b7c5f433 Chong Qiao 2023-12-11 168 }; 8248d42b7c5f433 Chong Qiao 2023-12-11 169 if (!timeout) 8248d42b7c5f433 Chong Qiao 2023-12-11 170 pr_info("bar not clear 0\n"); 8248d42b7c5f433 Chong Qiao 2023-12-11 171 8248d42b7c5f433 Chong Qiao 2023-12-11 172 pci_read_config_dword(ppdev, 0x0, &d); 8248d42b7c5f433 Chong Qiao 2023-12-11 173 pr_info("pcie port deviceid=0x%x recover begin\n", d); 8248d42b7c5f433 Chong Qiao 2023-12-11 174 retrain: 8248d42b7c5f433 Chong Qiao 2023-12-11 175 while (1) { 8248d42b7c5f433 Chong Qiao 2023-12-11 176 pci_write_config_dword(ppdev, index[0], data[0]); 8248d42b7c5f433 Chong Qiao 2023-12-11 177 pci_read_config_dword(ppdev, index[0], &d); 8248d42b7c5f433 Chong Qiao 2023-12-11 178 d &= ~0xf; 8248d42b7c5f433 Chong Qiao 2023-12-11 179 if (d) 8248d42b7c5f433 Chong Qiao 2023-12-11 180 break; 8248d42b7c5f433 Chong Qiao 2023-12-11 181 mdelay(1); 8248d42b7c5f433 Chong Qiao 2023-12-11 182 } 8248d42b7c5f433 Chong Qiao 2023-12-11 183 8248d42b7c5f433 Chong Qiao 2023-12-11 184 while (1) { 8248d42b7c5f433 Chong Qiao 2023-12-11 185 for (i = 0; i < ARRAY_SIZE(index); i++) { 8248d42b7c5f433 Chong Qiao 2023-12-11 186 if (index[i] != 0x18 && index[i] != 0x1c && index[i] != 0x20) 8248d42b7c5f433 Chong Qiao 2023-12-11 187 pci_write_config_dword(ppdev, index[i], data[i]); 8248d42b7c5f433 Chong Qiao 2023-12-11 188 } 8248d42b7c5f433 Chong Qiao 2023-12-11 189 pci_write_config_dword(ppdev, 0x80c, d80c); 8248d42b7c5f433 Chong Qiao 2023-12-11 190 pci_write_config_dword(ppdev, 0x71c, d71c); 8248d42b7c5f433 Chong Qiao 2023-12-11 191 8248d42b7c5f433 Chong Qiao 2023-12-11 192 pci_read_config_dword(ppdev, 0x10, &d); 8248d42b7c5f433 Chong Qiao 2023-12-11 193 d &= ~0xf; 8248d42b7c5f433 Chong Qiao 2023-12-11 194 if (d) 8248d42b7c5f433 Chong Qiao 2023-12-11 195 break; 8248d42b7c5f433 Chong Qiao 2023-12-11 196 mdelay(1); 8248d42b7c5f433 Chong Qiao 2023-12-11 197 } 8248d42b7c5f433 Chong Qiao 2023-12-11 198 8248d42b7c5f433 Chong Qiao 2023-12-11 199 timeout = 10000; 8248d42b7c5f433 Chong Qiao 2023-12-11 200 8248d42b7c5f433 Chong Qiao 2023-12-11 @201 writel(ctrl | 0x8, p); 8248d42b7c5f433 Chong Qiao 2023-12-11 202 while (1) { 8248d42b7c5f433 Chong Qiao 2023-12-11 203 d = readl(p + 0xc); 8248d42b7c5f433 Chong Qiao 2023-12-11 204 if ((d & 0x11) == 0x11) { 8248d42b7c5f433 Chong Qiao 2023-12-11 205 break; 8248d42b7c5f433 Chong Qiao 2023-12-11 206 } else if (!timeout) { 8248d42b7c5f433 Chong Qiao 2023-12-11 207 pr_info("pcie train failed status=0x%x\n", d); 8248d42b7c5f433 Chong Qiao 2023-12-11 208 goto out; 8248d42b7c5f433 Chong Qiao 2023-12-11 209 } 8248d42b7c5f433 Chong Qiao 2023-12-11 210 mdelay(1); 8248d42b7c5f433 Chong Qiao 2023-12-11 211 timeout--; 8248d42b7c5f433 Chong Qiao 2023-12-11 212 } 8248d42b7c5f433 Chong Qiao 2023-12-11 213 8248d42b7c5f433 Chong Qiao 2023-12-11 214 8248d42b7c5f433 Chong Qiao 2023-12-11 215 pr_info("pcie recovered done\n"); 8248d42b7c5f433 Chong Qiao 2023-12-11 216 8248d42b7c5f433 Chong Qiao 2023-12-11 217 if (!retry) { 8248d42b7c5f433 Chong Qiao 2023-12-11 218 /*wait u-boot ddr config */ 8248d42b7c5f433 Chong Qiao 2023-12-11 219 set_current_state(TASK_UNINTERRUPTIBLE); 8248d42b7c5f433 Chong Qiao 2023-12-11 220 schedule_timeout(HZ*resetbootwait); 8248d42b7c5f433 Chong Qiao 2023-12-11 221 set_current_state(TASK_RUNNING); 8248d42b7c5f433 Chong Qiao 2023-12-11 222 pci_read_config_dword(ppdev, 0x10, &d); 8248d42b7c5f433 Chong Qiao 2023-12-11 223 d &= ~0xf; 8248d42b7c5f433 Chong Qiao 2023-12-11 224 if (!d) { 8248d42b7c5f433 Chong Qiao 2023-12-11 225 retry = 1; 8248d42b7c5f433 Chong Qiao 2023-12-11 226 goto retrain; 8248d42b7c5f433 Chong Qiao 2023-12-11 227 } 8248d42b7c5f433 Chong Qiao 2023-12-11 228 } 8248d42b7c5f433 Chong Qiao 2023-12-11 229 } else { 8248d42b7c5f433 Chong Qiao 2023-12-11 230 set_current_state(TASK_UNINTERRUPTIBLE); 8248d42b7c5f433 Chong Qiao 2023-12-11 231 schedule_timeout(HZ*resetbootwait); 8248d42b7c5f433 Chong Qiao 2023-12-11 232 set_current_state(TASK_RUNNING); 8248d42b7c5f433 Chong Qiao 2023-12-11 233 } 8248d42b7c5f433 Chong Qiao 2023-12-11 234 local_bh_disable(); 8248d42b7c5f433 Chong Qiao 2023-12-11 235 pciebreak_smp_send_stop(10000); 8248d42b7c5f433 Chong Qiao 2023-12-11 236 wmb(); /* flush all write before we update pcie window */ 8248d42b7c5f433 Chong Qiao 2023-12-11 237 for (i = 0; i < ARRAY_SIZE(index); i++) 8248d42b7c5f433 Chong Qiao 2023-12-11 238 pci_write_config_dword(ppdev, index[i], data[i]); 8248d42b7c5f433 Chong Qiao 2023-12-11 239 8248d42b7c5f433 Chong Qiao 2023-12-11 240 for (i = 0; i < ARRAY_SIZE(cindex); i++) 8248d42b7c5f433 Chong Qiao 2023-12-11 241 pci_write_config_dword(pdev, cindex[i], cdata[i]); 8248d42b7c5f433 Chong Qiao 2023-12-11 242 atomic_set(&waiting_for_pciebreak_ipi, 0); 8248d42b7c5f433 Chong Qiao 2023-12-11 243 wmb(); /* flush all write after we update pcie window */ 8248d42b7c5f433 Chong Qiao 2023-12-11 244 local_bh_enable(); 8248d42b7c5f433 Chong Qiao 2023-12-11 245 8248d42b7c5f433 Chong Qiao 2023-12-11 246 8248d42b7c5f433 Chong Qiao 2023-12-11 247 pr_info("redraw console\n"); 8248d42b7c5f433 Chong Qiao 2023-12-11 248 8248d42b7c5f433 Chong Qiao 2023-12-11 249 saved_console = fg_console; 8248d42b7c5f433 Chong Qiao 2023-12-11 250 switch_console(fg_console > 0?fg_console - 1 : fg_console + 1); 8248d42b7c5f433 Chong Qiao 2023-12-11 251 queue_delayed_work(priv->wq, &priv->redraw_work, HZ); 8248d42b7c5f433 Chong Qiao 2023-12-11 252 out: 8248d42b7c5f433 Chong Qiao 2023-12-11 253 priv->running = 0; 8248d42b7c5f433 Chong Qiao 2023-12-11 254 } 8248d42b7c5f433 Chong Qiao 2023-12-11 255 8248d42b7c5f433 Chong Qiao 2023-12-11 256 irqreturn_t ls2k500sfb_interrupt(int irq, void *arg) 8248d42b7c5f433 Chong Qiao 2023-12-11 257 { 8248d42b7c5f433 Chong Qiao 2023-12-11 258 struct ls2k500sfb_struct *priv = arg; 8248d42b7c5f433 Chong Qiao 2023-12-11 259 struct pci_dev *pdev = priv->dev; 8248d42b7c5f433 Chong Qiao 2023-12-11 260 8248d42b7c5f433 Chong Qiao 2023-12-11 261 if (irq == pdev->irq) 8248d42b7c5f433 Chong Qiao 2023-12-11 262 pr_info("ls2k500sfb pcie interrupt\n"); 8248d42b7c5f433 Chong Qiao 2023-12-11 263 else 8248d42b7c5f433 Chong Qiao 2023-12-11 264 pr_info("ls2k500sfb gpio interrupt\n"); 8248d42b7c5f433 Chong Qiao 2023-12-11 265 if (system_state != SYSTEM_RUNNING) 8248d42b7c5f433 Chong Qiao 2023-12-11 266 return IRQ_HANDLED; 8248d42b7c5f433 Chong Qiao 2023-12-11 267 8248d42b7c5f433 Chong Qiao 2023-12-11 268 if (!priv->running) { 8248d42b7c5f433 Chong Qiao 2023-12-11 269 if (!resetdelay || time_after(jiffies, priv->reset_time + resetdelay * HZ)) { 8248d42b7c5f433 Chong Qiao 2023-12-11 270 priv->running = 1; 8248d42b7c5f433 Chong Qiao 2023-12-11 271 queue_work(priv->wq, &priv->work); 8248d42b7c5f433 Chong Qiao 2023-12-11 272 } 8248d42b7c5f433 Chong Qiao 2023-12-11 273 priv->reset_time = jiffies; 8248d42b7c5f433 Chong Qiao 2023-12-11 274 } 8248d42b7c5f433 Chong Qiao 2023-12-11 275 return IRQ_HANDLED; 8248d42b7c5f433 Chong Qiao 2023-12-11 276 } 8248d42b7c5f433 Chong Qiao 2023-12-11 277 8248d42b7c5f433 Chong Qiao 2023-12-11 278 #ifdef CONFIG_LOONGARCH 8248d42b7c5f433 Chong Qiao 2023-12-11 279 #define GPIO_OEN ((void *)IO_BASE+0x1fe00000+0x500) 8248d42b7c5f433 Chong Qiao 2023-12-11 280 #define GPIO_FUNCEN ((void *)IO_BASE+0x1fe00000+0x504) 8248d42b7c5f433 Chong Qiao 2023-12-11 281 #define GPIO_OUT ((void *)IO_BASE+0x1fe00000+0x508) 8248d42b7c5f433 Chong Qiao 2023-12-11 282 #define GPIO_IN ((void *)IO_BASE+0x1fe00000+0x50c) 8248d42b7c5f433 Chong Qiao 2023-12-11 283 #define GPIO_INTPOL ((void *)IO_BASE+0x1fe00000+0x510) 8248d42b7c5f433 Chong Qiao 2023-12-11 284 #define GPIO_INTEN ((void *)IO_BASE+0x1fe00000+0x514) 8248d42b7c5f433 Chong Qiao 2023-12-11 285 8248d42b7c5f433 Chong Qiao 2023-12-11 286 static int gpiochip_match_name(struct gpio_chip *chip, void *data) 8248d42b7c5f433 Chong Qiao 2023-12-11 287 { 8248d42b7c5f433 Chong Qiao 2023-12-11 288 const char *name = data; 8248d42b7c5f433 Chong Qiao 2023-12-11 289 8248d42b7c5f433 Chong Qiao 2023-12-11 290 return !strcmp(chip->label, name); 8248d42b7c5f433 Chong Qiao 2023-12-11 291 } 8248d42b7c5f433 Chong Qiao 2023-12-11 292 static int get_gpio_irq_from_acpi_table(int gpio) 8248d42b7c5f433 Chong Qiao 2023-12-11 293 { 8248d42b7c5f433 Chong Qiao 2023-12-11 294 struct gpio_chip *chip; 8248d42b7c5f433 Chong Qiao 2023-12-11 295 struct gpio_desc *desc; 8248d42b7c5f433 Chong Qiao 2023-12-11 296 8248d42b7c5f433 Chong Qiao 2023-12-11 297 chip = gpiochip_find("LOON0007:00", gpiochip_match_name); 8248d42b7c5f433 Chong Qiao 2023-12-11 298 if (!chip) 8248d42b7c5f433 Chong Qiao 2023-12-11 299 return -ENOENT; 8248d42b7c5f433 Chong Qiao 2023-12-11 300 desc = gpiochip_request_own_desc(chip, gpio, "reboot", GPIO_LOOKUP_FLAGS_DEFAULT, GPIOD_IN); 8248d42b7c5f433 Chong Qiao 2023-12-11 301 if (!desc) 8248d42b7c5f433 Chong Qiao 2023-12-11 302 return -ENOENT; 8248d42b7c5f433 Chong Qiao 2023-12-11 303 return gpiod_to_irq(desc); 8248d42b7c5f433 Chong Qiao 2023-12-11 304 } 8248d42b7c5f433 Chong Qiao 2023-12-11 305 8248d42b7c5f433 Chong Qiao 2023-12-11 306 static int get_gpio_irq_from_acpi_gsi(int gpio) 8248d42b7c5f433 Chong Qiao 2023-12-11 307 { 8248d42b7c5f433 Chong Qiao 2023-12-11 308 int gsi = 16 + (gpio & 7); 8248d42b7c5f433 Chong Qiao 2023-12-11 309 8248d42b7c5f433 Chong Qiao 2023-12-11 310 return acpi_register_gsi(NULL, gsi, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW); 8248d42b7c5f433 Chong Qiao 2023-12-11 311 } 8248d42b7c5f433 Chong Qiao 2023-12-11 312 8248d42b7c5f433 Chong Qiao 2023-12-11 313 static int register_gpio_reboot_handler(struct ls2k500sfb_struct *priv) 8248d42b7c5f433 Chong Qiao 2023-12-11 314 { 8248d42b7c5f433 Chong Qiao 2023-12-11 315 int irq = get_gpio_irq_from_acpi_table(GPIO); 8248d42b7c5f433 Chong Qiao 2023-12-11 316 8248d42b7c5f433 Chong Qiao 2023-12-11 317 if (irq < 0) { 8248d42b7c5f433 Chong Qiao 2023-12-11 318 irq = get_gpio_irq_from_acpi_gsi(GPIO); 8248d42b7c5f433 Chong Qiao 2023-12-11 319 pr_notice("gsi gpio irq %d\n", irq); 8248d42b7c5f433 Chong Qiao 2023-12-11 320 } else 8248d42b7c5f433 Chong Qiao 2023-12-11 321 pr_notice("acpi gpio irq %d\n", irq); 8248d42b7c5f433 Chong Qiao 2023-12-11 @322 writel(readl(GPIO_OEN) | (0x1 << GPIO), GPIO_OEN); 8248d42b7c5f433 Chong Qiao 2023-12-11 323 writel(readl(GPIO_FUNCEN) & ~(0x1 << GPIO), GPIO_FUNCEN); 8248d42b7c5f433 Chong Qiao 2023-12-11 324 writel(readl(GPIO_INTPOL) & ~(0x1 << GPIO), GPIO_INTPOL); 8248d42b7c5f433 Chong Qiao 2023-12-11 325 writel(readl(GPIO_INTEN) | (0x1 << GPIO), GPIO_INTEN); 8248d42b7c5f433 Chong Qiao 2023-12-11 326 if (request_irq(irq, ls2k500sfb_interrupt, IRQF_SHARED | IRQF_TRIGGER_FALLING, 8248d42b7c5f433 Chong Qiao 2023-12-11 327 "ls2k500sfb", priv)) 8248d42b7c5f433 Chong Qiao 2023-12-11 328 pr_err("request_irq(%d) failed\n", irq); 8248d42b7c5f433 Chong Qiao 2023-12-11 329 return 0; 8248d42b7c5f433 Chong Qiao 2023-12-11 330 } 8248d42b7c5f433 Chong Qiao 2023-12-11 331 #endif 8248d42b7c5f433 Chong Qiao 2023-12-11 332 :::::: The code at line 322 was first introduced by commit :::::: 8248d42b7c5f4338a54f26d8efebec8614b43466 fbdev: add ls2k500sfb driver for ls2k500 bmc. :::::: TO: Chong Qiao <qiaochong(a)loongson.cn> :::::: CC: Hongchen Zhang <zhanghongchen(a)loongson.cn> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD SUCCESS 3b421b6002e287e38790cbdad4a3e08baf7e1bc4
by kernel test robot 07 Jul '24

07 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 3b421b6002e287e38790cbdad4a3e08baf7e1bc4 !9770 Add a switch to enable hungtask check for io Warning ids grouped by kconfigs: recent_errors `-- arm64-allmodconfig `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag elapsed time: 723m configs tested: 38 configs skipped: 123 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240706 gcc-13.2.0 arm64 randconfig-002-20240706 gcc-13.2.0 arm64 randconfig-003-20240706 clang-16 arm64 randconfig-004-20240706 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240706 gcc-13.2.0 loongarch randconfig-002-20240706 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240706 clang-18 x86_64 buildonly-randconfig-002-20240706 clang-18 x86_64 buildonly-randconfig-003-20240706 clang-18 x86_64 buildonly-randconfig-004-20240706 clang-18 x86_64 buildonly-randconfig-005-20240706 gcc-13 x86_64 buildonly-randconfig-006-20240706 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240706 gcc-9 x86_64 randconfig-002-20240706 clang-18 x86_64 randconfig-003-20240706 clang-18 x86_64 randconfig-004-20240706 clang-18 x86_64 randconfig-005-20240706 clang-18 x86_64 randconfig-006-20240706 clang-18 x86_64 randconfig-011-20240706 gcc-12 x86_64 randconfig-012-20240706 gcc-12 x86_64 randconfig-013-20240706 clang-18 x86_64 randconfig-014-20240706 gcc-13 x86_64 randconfig-015-20240706 gcc-13 x86_64 randconfig-016-20240706 gcc-13 x86_64 randconfig-071-20240706 gcc-12 x86_64 randconfig-072-20240706 gcc-13 x86_64 randconfig-073-20240706 gcc-12 x86_64 randconfig-074-20240706 gcc-13 x86_64 randconfig-075-20240706 clang-18 x86_64 randconfig-076-20240706 gcc-13 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10] BUILD SUCCESS 1cc61a82256cf82a5f06287eb7c64d9b94f43786
by kernel test robot 07 Jul '24

07 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 1cc61a82256cf82a5f06287eb7c64d9b94f43786 !9792 v3 net: fix one NULL pointer dereference bug in net_rship module Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 727m configs tested: 34 configs skipped: 126 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240706 gcc-13.2.0 arm64 randconfig-002-20240706 gcc-13.2.0 arm64 randconfig-003-20240706 clang-16 arm64 randconfig-004-20240706 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240706 clang-18 x86_64 buildonly-randconfig-002-20240706 clang-18 x86_64 buildonly-randconfig-003-20240706 clang-18 x86_64 buildonly-randconfig-004-20240706 clang-18 x86_64 buildonly-randconfig-005-20240706 gcc-13 x86_64 buildonly-randconfig-006-20240706 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240706 gcc-9 x86_64 randconfig-002-20240706 clang-18 x86_64 randconfig-003-20240706 clang-18 x86_64 randconfig-004-20240706 clang-18 x86_64 randconfig-005-20240706 clang-18 x86_64 randconfig-006-20240706 clang-18 x86_64 randconfig-011-20240706 gcc-12 x86_64 randconfig-012-20240706 gcc-12 x86_64 randconfig-013-20240706 clang-18 x86_64 randconfig-014-20240706 gcc-13 x86_64 randconfig-015-20240706 gcc-13 x86_64 randconfig-016-20240706 gcc-13 x86_64 randconfig-071-20240706 gcc-12 x86_64 randconfig-072-20240706 gcc-13 x86_64 randconfig-073-20240706 gcc-12 x86_64 randconfig-074-20240706 gcc-13 x86_64 randconfig-075-20240706 clang-18 x86_64 randconfig-076-20240706 gcc-13 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS d127ee13b4d5627947830da5f044541d1144dc44
by kernel test robot 07 Jul '24

07 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: d127ee13b4d5627947830da5f044541d1144dc44 !9797 sch_cake: do not call cake_destroy() from cake_init() elapsed time: 726m configs tested: 34 configs skipped: 127 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240706 gcc-13.2.0 arm64 randconfig-002-20240706 gcc-13.2.0 arm64 randconfig-003-20240706 gcc-13.2.0 arm64 randconfig-004-20240706 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240706 clang-18 x86_64 buildonly-randconfig-002-20240706 clang-18 x86_64 buildonly-randconfig-003-20240706 clang-18 x86_64 buildonly-randconfig-004-20240706 clang-18 x86_64 buildonly-randconfig-005-20240706 gcc-13 x86_64 buildonly-randconfig-006-20240706 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240706 gcc-9 x86_64 randconfig-002-20240706 clang-18 x86_64 randconfig-003-20240706 clang-18 x86_64 randconfig-004-20240706 clang-18 x86_64 randconfig-005-20240706 clang-18 x86_64 randconfig-006-20240706 clang-18 x86_64 randconfig-011-20240706 gcc-12 x86_64 randconfig-012-20240706 gcc-12 x86_64 randconfig-013-20240706 clang-18 x86_64 randconfig-014-20240706 gcc-13 x86_64 randconfig-015-20240706 gcc-13 x86_64 randconfig-016-20240706 gcc-13 x86_64 randconfig-071-20240706 gcc-12 x86_64 randconfig-072-20240706 gcc-13 x86_64 randconfig-073-20240706 gcc-12 x86_64 randconfig-074-20240706 gcc-13 x86_64 randconfig-075-20240706 clang-18 x86_64 randconfig-076-20240706 gcc-13 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
by Li Nan 06 Jul '24

06 Jul '24

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit a2db328b0839312c169eb42746ec46fc1ab53ed2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D6H CVE: CVE-2024-36478 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Writing 'power' and 'submit_queues' concurrently will trigger kernel panic: Test script: modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done Test result: BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: <TASK> lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Reported-and-tested-by: Yi Zhang <yi.zhang(a)redhat.com> Closes: https://lore.kernel.org/all/CAHj4cs9LgsHLnjg8z06LQ3Pr5cax-+Ps+xT7AP7TPnEjSt… Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Zhu Yanjun <yanjun.zhu(a)linux.dev> Link: https://lore.kernel.org/r/20240523153934.1937851-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: drivers/block/null_blk/main.c [ A lot of conflict, this patch just expand the protection range of mutex, ignore conflict. ] Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/block/null_blk/main.c | 43 +++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c index 35b390a785dd..91c8412442d0 100644 --- a/drivers/block/null_blk/main.c +++ b/drivers/block/null_blk/main.c @@ -323,11 +323,9 @@ CONFIGFS_ATTR(nullb_device_, NAME); static int nullb_apply_submit_queues(struct nullb_device *dev, unsigned int submit_queues) { - struct nullb *nullb = dev->nullb; + struct nullb *nullb; struct blk_mq_tag_set *set; - - if (!nullb) - return 0; + int ret = 0; /* * Make sure that null_init_hctx() does not access nullb->queues[] past @@ -335,9 +333,20 @@ static int nullb_apply_submit_queues(struct nullb_device *dev, */ if (submit_queues > nr_cpu_ids) return -EINVAL; + + mutex_lock(&lock); + + nullb = dev->nullb; + if (!nullb) + goto out; + set = nullb->tag_set; blk_mq_update_nr_hw_queues(set, submit_queues); - return set->nr_hw_queues == submit_queues ? 0 : -ENOMEM; + ret = set->nr_hw_queues == submit_queues ? 0 : -ENOMEM; + +out: + mutex_unlock(&lock); + return ret; } NULLB_DEVICE_ATTR(size, ulong, NULL); @@ -378,27 +387,31 @@ static ssize_t nullb_device_power_store(struct config_item *item, if (ret < 0) return ret; + ret = count; + mutex_lock(&lock); if (!dev->power && newp) { if (test_and_set_bit(NULLB_DEV_FL_UP, &dev->flags)) - return count; + goto out; + if (null_add_dev(dev)) { clear_bit(NULLB_DEV_FL_UP, &dev->flags); - return -ENOMEM; + ret = -ENOMEM; + goto out; } set_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); dev->power = newp; } else if (dev->power && !newp) { if (test_and_clear_bit(NULLB_DEV_FL_UP, &dev->flags)) { - mutex_lock(&lock); dev->power = newp; null_del_dev(dev->nullb); - mutex_unlock(&lock); } clear_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); } - return count; +out: + mutex_unlock(&lock); + return ret; } CONFIGFS_ATTR(nullb_device_, power); @@ -1880,15 +1893,11 @@ static int null_add_dev(struct nullb_device *dev) blk_queue_flag_set(QUEUE_FLAG_NONROT, nullb->q); blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, nullb->q); - mutex_lock(&lock); rv = ida_simple_get(&nullb_indexes, 0, 0, GFP_KERNEL); - if (rv < 0) { - mutex_unlock(&lock); + if (rv < 0) goto out_cleanup_zone; - } nullb->index = rv; dev->index = rv; - mutex_unlock(&lock); blk_queue_logical_block_size(nullb->q, dev->blocksize); blk_queue_physical_block_size(nullb->q, dev->blocksize); @@ -1901,9 +1910,7 @@ static int null_add_dev(struct nullb_device *dev) if (rv) goto out_ida_free; - mutex_lock(&lock); list_add_tail(&nullb->list, &nullb_list); - mutex_unlock(&lock); return 0; @@ -1985,7 +1992,9 @@ static int __init null_init(void) ret = -ENOMEM; goto err_dev; } + mutex_lock(&lock); ret = null_add_dev(dev); + mutex_unlock(&lock); if (ret) { null_free_dev(dev); goto err_dev; -- 2.39.2

2 1

[PATCH OLK-5.10] null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
by Li Nan 06 Jul '24

06 Jul '24

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit a2db328b0839312c169eb42746ec46fc1ab53ed2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D6H CVE: CVE-2024-36478 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Writing 'power' and 'submit_queues' concurrently will trigger kernel panic: Test script: modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done Test result: BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: <TASK> lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Reported-and-tested-by: Yi Zhang <yi.zhang(a)redhat.com> Closes: https://lore.kernel.org/all/CAHj4cs9LgsHLnjg8z06LQ3Pr5cax-+Ps+xT7AP7TPnEjSt… Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Zhu Yanjun <yanjun.zhu(a)linux.dev> Link: https://lore.kernel.org/r/20240523153934.1937851-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: drivers/block/null_blk/main.c [ A lot of conflict, this patch just expand the protection range of mutex, ignore conflict. ] Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/block/null_blk/main.c | 43 +++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c index 35b390a785dd..91c8412442d0 100644 --- a/drivers/block/null_blk/main.c +++ b/drivers/block/null_blk/main.c @@ -323,11 +323,9 @@ CONFIGFS_ATTR(nullb_device_, NAME); static int nullb_apply_submit_queues(struct nullb_device *dev, unsigned int submit_queues) { - struct nullb *nullb = dev->nullb; + struct nullb *nullb; struct blk_mq_tag_set *set; - - if (!nullb) - return 0; + int ret = 0; /* * Make sure that null_init_hctx() does not access nullb->queues[] past @@ -335,9 +333,20 @@ static int nullb_apply_submit_queues(struct nullb_device *dev, */ if (submit_queues > nr_cpu_ids) return -EINVAL; + + mutex_lock(&lock); + + nullb = dev->nullb; + if (!nullb) + goto out; + set = nullb->tag_set; blk_mq_update_nr_hw_queues(set, submit_queues); - return set->nr_hw_queues == submit_queues ? 0 : -ENOMEM; + ret = set->nr_hw_queues == submit_queues ? 0 : -ENOMEM; + +out: + mutex_unlock(&lock); + return ret; } NULLB_DEVICE_ATTR(size, ulong, NULL); @@ -378,27 +387,31 @@ static ssize_t nullb_device_power_store(struct config_item *item, if (ret < 0) return ret; + ret = count; + mutex_lock(&lock); if (!dev->power && newp) { if (test_and_set_bit(NULLB_DEV_FL_UP, &dev->flags)) - return count; + goto out; + if (null_add_dev(dev)) { clear_bit(NULLB_DEV_FL_UP, &dev->flags); - return -ENOMEM; + ret = -ENOMEM; + goto out; } set_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); dev->power = newp; } else if (dev->power && !newp) { if (test_and_clear_bit(NULLB_DEV_FL_UP, &dev->flags)) { - mutex_lock(&lock); dev->power = newp; null_del_dev(dev->nullb); - mutex_unlock(&lock); } clear_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); } - return count; +out: + mutex_unlock(&lock); + return ret; } CONFIGFS_ATTR(nullb_device_, power); @@ -1880,15 +1893,11 @@ static int null_add_dev(struct nullb_device *dev) blk_queue_flag_set(QUEUE_FLAG_NONROT, nullb->q); blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, nullb->q); - mutex_lock(&lock); rv = ida_simple_get(&nullb_indexes, 0, 0, GFP_KERNEL); - if (rv < 0) { - mutex_unlock(&lock); + if (rv < 0) goto out_cleanup_zone; - } nullb->index = rv; dev->index = rv; - mutex_unlock(&lock); blk_queue_logical_block_size(nullb->q, dev->blocksize); blk_queue_physical_block_size(nullb->q, dev->blocksize); @@ -1901,9 +1910,7 @@ static int null_add_dev(struct nullb_device *dev) if (rv) goto out_ida_free; - mutex_lock(&lock); list_add_tail(&nullb->list, &nullb_list); - mutex_unlock(&lock); return 0; @@ -1985,7 +1992,9 @@ static int __init null_init(void) ret = -ENOMEM; goto err_dev; } + mutex_lock(&lock); ret = null_add_dev(dev); + mutex_unlock(&lock); if (ret) { null_free_dev(dev); goto err_dev; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] ftrace: Use preempt disable instead of rcu lock in ftrace_location_range()
by Zheng Yejian 06 Jul '24

06 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAA3U5 CVE: NA -------------------------------- After commit 5e66a5bdad69 ("ftrace: Fix rcu warn in ftrace_location()"), syzkaller reports following warning: WARNING: lock held when returning to user space! 4.18.0+ #16 Tainted: G W ---------r- - ------------------------------------------------ modprobe/4255 is leaving the kernel with locks still held! 1 lock held by modprobe/4255: #0: 0000000012ba3568 (rcu_read_lock){....}, at: ftrace_location_range+0x292/0x440 BUG: scheduling while atomic: modprobe/4255/0x00000002 ============================= BUG: scheduling while atomic: modprobe/4256/0x00000002 INFO: lockdep is turned off. Modules linked in: Kernel panic - not syncing: scheduling while atomic It seems that rcu_read_lock() is held but rcu_read_unlock() is not called, this is most likely due to the inconsistent state when calling in_atomic(). To fix it, use preemt_{disable,enable}_notrace() instead of rcu_read_{,un}lock(). Fixes: 5e66a5bdad69 ("ftrace: Fix rcu warn in ftrace_location()") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/ftrace.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index ad4440da5b78..ceb4bab432f1 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1581,12 +1581,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) key.ip = start; key.flags = end; /* overload flags, as it is unsigned long */ - /* - * It is in atomic context when called from ftrace_int3_handler(), - * in this case rcu lock is not needed. - */ - if (!in_atomic()) - rcu_read_lock(); + preempt_disable_notrace(); for (pg = ftrace_pages_start; pg; pg = pg->next) { if (pg->index == 0 || end < pg->records[0].ip || @@ -1600,8 +1595,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) break; } } - if (!in_atomic()) - rcu_read_unlock(); + preempt_enable_notrace(); return ip; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] sch_cake: do not call cake_destroy() from cake_init()
by Xiang Yang 06 Jul '24

06 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.222 commit 4e388232e630ebe4f94b4a0715ec98c0e2b314a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGX CVE: CVE-2021-47598 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit ab443c53916730862cec202078d36fd4008bea79 ] qdiscs are not supposed to call their own destroy() method from init(), because core stack already does that. syzbot was able to trigger use after free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline] WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Modules linked in: CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline] RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Call Trace: <TASK> tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [inline] tcf_block_put_ext net/sched/cls_api.c:1376 [inline] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1bb06badb9 Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2 </TASK> Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Link: https://lore.kernel.org/r/20211210142046.698336-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- net/sched/sch_cake.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c index 2025f0f559de..18c207b85d51 100644 --- a/net/sched/sch_cake.c +++ b/net/sched/sch_cake.c @@ -2675,7 +2675,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt, q->tins = kvcalloc(CAKE_MAX_TINS, sizeof(struct cake_tin_data), GFP_KERNEL); if (!q->tins) - goto nomem; + return -ENOMEM; for (i = 0; i < CAKE_MAX_TINS; i++) { struct cake_tin_data *b = q->tins + i; @@ -2705,10 +2705,6 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt, q->min_netlen = ~0; q->min_adjlen = ~0; return 0; - -nomem: - cake_destroy(sch); - return -ENOMEM; } static int cake_dump(struct Qdisc *sch, struct sk_buff *skb) -- 2.34.1

2 1

[PATCH OLK-5.10] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH OLK-6.6] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH OLK-5.10 v3] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 06 Jul '24

06 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 It is caused by null pointer dereference in net_rship module. The code path is as follows: ad_lacpdu_send dev_alloc_skb netdev_alloc_skb(NULL, length) // dev is NULL __netdev_alloc_skb(dev, length, GFP_ATOMIC) net_rship_skb_record_dev_rxinfo(skb, dev) // here dereference dev, it is NULL pointer, trigger issue. So we should add null pointer check to avoid the issue. Fixes: 64ba5634c4c6 ("net: add some bpf hooks in tcp stack for network numa relationship") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 4949c9455d5ad3ecd338b3fe8c5aafe54dfeacda
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 4949c9455d5ad3ecd338b3fe8c5aafe54dfeacda !9786 drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable() elapsed time: 733m configs tested: 34 configs skipped: 127 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD REGRESSION ea4dd5f0e87fde262e6fa081be0fb7f9e103057f
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: ea4dd5f0e87fde262e6fa081be0fb7f9e103057f !9649 f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag `-- x86_64-randconfig-014-20240705 |-- crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_subtype |-- ld:crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_free `-- ld:crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_subtype elapsed time: 730m configs tested: 38 configs skipped: 123 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10] BUILD SUCCESS 3486fdb9082a474750f2067f80fb835c2f480a18
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 3486fdb9082a474750f2067f80fb835c2f480a18 !9373 ALSA: core: Fix NULL module pointer assignment at card init Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 729m configs tested: 34 configs skipped: 127 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-27017
by Wang Hai 05 Jul '24

05 Jul '24

CVE-2024-27017 Pablo Neira Ayuso (3): netfilter: nft_set_pipapo: .walk does not deal with generations netfilter: nft_set_pipapo: walk over current view on netlink dump netfilter: nf_tables: missing iterator type in lookup walk include/net/netfilter/nf_tables.h | 13 +++++++++++++ net/netfilter/nf_tables_api.c | 6 ++++++ net/netfilter/nft_lookup.c | 1 + net/netfilter/nft_set_pipapo.c | 8 +++++++- 4 files changed, 27 insertions(+), 1 deletion(-) -- 2.17.1

2 4

[PATCH openEuler-22.03-LTS-SP1] clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
by Wang Hai 05 Jul '24

05 Jul '24

From: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> stable inclusion from stable-v5.10.201 commit 3994387ba3564976731179c4d4a6d7850ddda71a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFZV CVE: CVE-2023-52873 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f57f78fbacf630430bf954e5a84caafdfea30c0 ] Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support") Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> Link: https://lore.kernel.org/r/20230912093407.21505-2-jiasheng@iscas.ac.cn Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/clk/mediatek/clk-mt6779.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c index 6e0d3a166729..cf720651fc53 100644 --- a/drivers/clk/mediatek/clk-mt6779.c +++ b/drivers/clk/mediatek/clk-mt6779.c @@ -1216,6 +1216,8 @@ static int clk_mt6779_apmixed_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data); @@ -1236,6 +1238,8 @@ static int clk_mt6779_top_probe(struct platform_device *pdev) return PTR_ERR(base); clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks), clk_data); -- 2.17.1

2 1

[PATCH OLK-5.10 v2] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 Fixes: 64ba5634c4c6 ("net: add some bpf hooks in tcp stack for network numa relationship") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[openeuler:OLK-6.6 3342/10589] crypto/asymmetric_keys/pgp_public_key.c:359:undefined reference to `public_key_subtype'
by kernel test robot 05 Jul '24

05 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 17b5ba51d6bc20767e5e5c03df0acf15609b6d11 commit: 43d4042e06d2bf96adf67d25e8d91653507a4cf9 [3342/10589] KEYS: Provide a function to load keys from a PGP keyring blob config: x86_64-randconfig-014-20240705 (https://download.01.org/0day-ci/archive/20240705/202407051911.Va4emssv-lkp@…) compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240705/202407051911.Va4emssv-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202407051911.Va4emssv-lkp@intel.com/ All errors (new ones prefixed by >>): ld: vmlinux.o: in function `pgp_key_parse': >> crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11e1c): undefined reference to `public_key_subtype' >> ld: crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11e3b): undefined reference to `public_key_subtype' ld: crypto/asymmetric_keys/pgp_public_key.c:360:(.text+0x1b11e67): undefined reference to `public_key_subtype' >> ld: crypto/asymmetric_keys/pgp_public_key.c:369:(.text+0x1b11f38): undefined reference to `public_key_free' ld: crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11fbf): undefined reference to `public_key_subtype' Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for PGP_KEY_PARSER Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=n] Selected by [y]: - PGP_PRELOAD [=y] && CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] vim +359 crypto/asymmetric_keys/pgp_public_key.c 4e59d757dc3f7f Roberto Sassu 2023-09-12 300 4e59d757dc3f7f Roberto Sassu 2023-09-12 301 /* 4e59d757dc3f7f Roberto Sassu 2023-09-12 302 * Attempt to parse the instantiation data blob for a key as a PGP packet 4e59d757dc3f7f Roberto Sassu 2023-09-12 303 * message holding a key. 4e59d757dc3f7f Roberto Sassu 2023-09-12 304 */ 4e59d757dc3f7f Roberto Sassu 2023-09-12 305 static int pgp_key_parse(struct key_preparsed_payload *prep) 4e59d757dc3f7f Roberto Sassu 2023-09-12 306 { 4e59d757dc3f7f Roberto Sassu 2023-09-12 307 struct pgp_key_data_parse_context ctx; 4e59d757dc3f7f Roberto Sassu 2023-09-12 308 int ret; 4e59d757dc3f7f Roberto Sassu 2023-09-12 309 4e59d757dc3f7f Roberto Sassu 2023-09-12 310 kenter(""); 4e59d757dc3f7f Roberto Sassu 2023-09-12 311 4e59d757dc3f7f Roberto Sassu 2023-09-12 312 memset(&ctx, 0, sizeof(ctx)); e8c01f299ab793 David Howells 2023-09-12 313 ctx.pgp.types_of_interest = (1 << PGP_PKT_PUBLIC_KEY) | e8c01f299ab793 David Howells 2023-09-12 314 (1 << PGP_PKT_USER_ID); 4e59d757dc3f7f Roberto Sassu 2023-09-12 315 ctx.pgp.process_packet = pgp_process_public_key; 4e59d757dc3f7f Roberto Sassu 2023-09-12 316 4e59d757dc3f7f Roberto Sassu 2023-09-12 317 ret = pgp_parse_packets(prep->data, prep->datalen, &ctx.pgp); 4e59d757dc3f7f Roberto Sassu 2023-09-12 318 if (ret < 0) 4e59d757dc3f7f Roberto Sassu 2023-09-12 319 goto error; 4e59d757dc3f7f Roberto Sassu 2023-09-12 320 e8c01f299ab793 David Howells 2023-09-12 321 if (!ctx.fingerprint) { e8c01f299ab793 David Howells 2023-09-12 322 ret = -EINVAL; e8c01f299ab793 David Howells 2023-09-12 323 goto error; e8c01f299ab793 David Howells 2023-09-12 324 } e8c01f299ab793 David Howells 2023-09-12 325 e8c01f299ab793 David Howells 2023-09-12 326 if (ctx.user_id && ctx.user_id_len > 0) { e8c01f299ab793 David Howells 2023-09-12 327 /* Propose a description for the key e8c01f299ab793 David Howells 2023-09-12 328 * (user ID without the comment) e8c01f299ab793 David Howells 2023-09-12 329 */ e8c01f299ab793 David Howells 2023-09-12 330 size_t ulen = ctx.user_id_len, flen = ctx.fingerprint_len; e8c01f299ab793 David Howells 2023-09-12 331 const char *p; e8c01f299ab793 David Howells 2023-09-12 332 e8c01f299ab793 David Howells 2023-09-12 333 p = memchr(ctx.user_id, '(', ulen); e8c01f299ab793 David Howells 2023-09-12 334 if (p) { e8c01f299ab793 David Howells 2023-09-12 335 /* Remove the comment */ e8c01f299ab793 David Howells 2023-09-12 336 do { e8c01f299ab793 David Howells 2023-09-12 337 p--; e8c01f299ab793 David Howells 2023-09-12 338 } while (*p == ' ' && p > ctx.user_id); e8c01f299ab793 David Howells 2023-09-12 339 if (*p != ' ') e8c01f299ab793 David Howells 2023-09-12 340 p++; e8c01f299ab793 David Howells 2023-09-12 341 ulen = p - ctx.user_id; e8c01f299ab793 David Howells 2023-09-12 342 } e8c01f299ab793 David Howells 2023-09-12 343 e8c01f299ab793 David Howells 2023-09-12 344 if (ulen > 255 - 9) e8c01f299ab793 David Howells 2023-09-12 345 ulen = 255 - 9; e8c01f299ab793 David Howells 2023-09-12 346 prep->description = kmalloc(ulen + 1 + 8 + 1, GFP_KERNEL); e8c01f299ab793 David Howells 2023-09-12 347 ret = -ENOMEM; e8c01f299ab793 David Howells 2023-09-12 348 if (!prep->description) e8c01f299ab793 David Howells 2023-09-12 349 goto error; e8c01f299ab793 David Howells 2023-09-12 350 memcpy(prep->description, ctx.user_id, ulen); e8c01f299ab793 David Howells 2023-09-12 351 prep->description[ulen] = ' '; e8c01f299ab793 David Howells 2023-09-12 352 memcpy(prep->description + ulen + 1, e8c01f299ab793 David Howells 2023-09-12 353 ctx.fingerprint + flen - 8, 8); e8c01f299ab793 David Howells 2023-09-12 354 prep->description[ulen + 9] = 0; e8c01f299ab793 David Howells 2023-09-12 355 pr_debug("desc '%s'\n", prep->description); e8c01f299ab793 David Howells 2023-09-12 356 } e8c01f299ab793 David Howells 2023-09-12 357 4e59d757dc3f7f Roberto Sassu 2023-09-12 358 /* We're pinning the module by being linked against it */ 4e59d757dc3f7f Roberto Sassu 2023-09-12 @359 __module_get(public_key_subtype.owner); 4e59d757dc3f7f Roberto Sassu 2023-09-12 360 prep->payload.data[asym_subtype] = &public_key_subtype; 4e59d757dc3f7f Roberto Sassu 2023-09-12 361 prep->payload.data[asym_key_ids] = pgp_key_generate_id(&ctx); 4e59d757dc3f7f Roberto Sassu 2023-09-12 362 prep->payload.data[asym_crypto] = ctx.pub; 4e59d757dc3f7f Roberto Sassu 2023-09-12 363 prep->quotalen = 100; 4e59d757dc3f7f Roberto Sassu 2023-09-12 364 kfree(ctx.fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 365 kfree(ctx.raw_fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 366 return 0; 4e59d757dc3f7f Roberto Sassu 2023-09-12 367 4e59d757dc3f7f Roberto Sassu 2023-09-12 368 error: 4e59d757dc3f7f Roberto Sassu 2023-09-12 @369 public_key_free(ctx.pub); 4e59d757dc3f7f Roberto Sassu 2023-09-12 370 kfree(ctx.fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 371 kfree(ctx.raw_fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 372 return ret; 4e59d757dc3f7f Roberto Sassu 2023-09-12 373 } 4e59d757dc3f7f Roberto Sassu 2023-09-12 374 :::::: The code at line 359 was first introduced by commit :::::: 4e59d757dc3f7f2e2a646a2e3f0f271ae4599eeb KEYS: PGP data parser :::::: TO: Roberto Sassu <roberto.sassu(a)huawei.com> :::::: CC: zgzxx <zhangguangzhi3(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] net: fix wrong return value in bpf_sock_ops_get_uid_gid
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I8KU3B CVE: NA -------------------------------- We should return 0 on success. Fixes: e62b4a1c5593 ("bpf: Add bpf_get_sockops_uid_gid helper function") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/filter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/filter.c b/net/core/filter.c index 6ec353bf36f3..c88f51f7d3f9 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -5675,7 +5675,7 @@ static int bpf_sock_ops_get_uid_gid(struct bpf_sock_ops_kern *bpf_sock, *(u32 *)optval = from_kgid_munged(sock_net(sk)->user_ns, gid); *((u32 *)optval + 1) = from_kuid_munged(sock_net(sk)->user_ns, uid); - return sizeof(u64); + return 0; } static int bpf_sk_original_addr(struct bpf_sock_ops_kern *bpf_sock, -- 2.34.1

2 1

[PATCH OLK-5.10] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ----------------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[PATCH OLK-5.10 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

1 0

[openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[PATCH OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] CVE-2024-39461
by Yongqiang Liu 05 Jul '24

05 Jul '24

Nathan Chancellor (1): clk: bcm: rpi: Assign ->num before accessing ->hws drivers/clk/bcm/clk-raspberrypi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/core/cec-adap.c | 3 +-- drivers/media/cec/core/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

CVE-2024-23848 Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/cec-adap.c | 3 +-- drivers/media/cec/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 05 Jul '24

05 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6] mm/slub: Reduce memory consumption in extreme scenarios
by Liu Shixin 05 Jul '24

05 Jul '24

From: Chen Jun <chenjun102(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit 9198ffbd2b494daae3a67cac1d59c3a2754e64cd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAATAS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, on the following allocation it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, when a preferred node is indicated (not NUMA_NO_NODE) but without a prior __GFP_THISNODE constraint: 1) try to get a partial slab from target node only by having __GFP_THISNODE in pc.flags for get_partial() 2) if 1) failed, try to allocate a new slab from target node with GFP_NOWAIT | __GFP_THISNODE opportunistically. 3) if 2) failed, retry with original gfpflags which will allow get_partial() try partial lists of other nodes before potentially allocating new page from other nodes Without a preferred node, or with __GFP_THISNODE constraint, the behavior remains unchanged. On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. cat /proc/slabinfo shows: kmalloc-256 4200530 13519712 256 32 2 : tunables.. after this patch, cat /proc/slabinfo shows: kmalloc-256 4200558 4200768 256 32 2 : tunables.. Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/slub.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index ee3e32cdb7fd..7fcd18261c1e 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2392,7 +2392,7 @@ static struct slab *get_partial(struct kmem_cache *s, int node, searchnode = numa_mem_id(); slab = get_partial_node(s, get_node(s, searchnode), pc); - if (slab || node != NUMA_NO_NODE) + if (slab || (node != NUMA_NO_NODE && (pc->flags & __GFP_THISNODE))) return slab; return get_any_partial(s, pc); @@ -3068,6 +3068,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, struct slab *slab; unsigned long flags; struct partial_context pc; + bool try_thisnode = true; stat(s, ALLOC_SLOWPATH); @@ -3194,6 +3195,21 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, new_objects: pc.flags = gfpflags; + /* + * When a preferred node is indicated but no __GFP_THISNODE + * + * 1) try to get a partial slab from target node only by having + * __GFP_THISNODE in pc.flags for get_partial() + * 2) if 1) failed, try to allocate a new slab from target node with + * GPF_NOWAIT | __GFP_THISNODE opportunistically + * 3) if 2) failed, retry with original gfpflags which will allow + * get_partial() try partial lists of other nodes before potentially + * allocating new page from other nodes + */ + if (unlikely(node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode)) + pc.flags = GFP_NOWAIT | __GFP_THISNODE; + pc.orig_size = orig_size; slab = get_partial(s, node, &pc); if (slab) { @@ -3215,10 +3231,15 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, } slub_put_cpu_ptr(s->cpu_slab); - slab = new_slab(s, gfpflags, node); + slab = new_slab(s, pc.flags, node); c = slub_get_cpu_ptr(s->cpu_slab); if (unlikely(!slab)) { + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode) { + try_thisnode = false; + goto new_objects; + } slab_out_of_memory(s, gfpflags, node); return NULL; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 05 Jul '24

05 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 3d96eef71e2b..ca0894de2ecd 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index eb9ab3d3a7b3..897ea85e04e4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2031,6 +2031,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2117,6 +2138,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2199,6 +2222,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH OLK-5.10] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index f625c42f48a3..358b9a5937a4 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 968f5b45062c..a73b400450ce 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2038,6 +2038,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2124,6 +2145,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2206,6 +2229,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/7] Sync bugfix from OLK-5.10
by Zheng Yejian 05 Jul '24

05 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Martin KaFai Lau (1): bpf: Check the other end of slot_type for STACK_SPILL Stanislav Fomichev (2): bpf: Don't EFAULT for getsockopt with optval=NULL bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 24 +++++++- kernel/bpf/verifier.c | 61 ++++++++++++------- .../testing/selftests/bpf/prog_tests/align.c | 4 +- 3 files changed, 61 insertions(+), 28 deletions(-) -- 2.25.1

2 8

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d !9765 i40e: Fix queues reservation for XDP Unverified Warning (likely false positive, please contact us if interested): drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->recv_buf' double freed drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->send_buf' double freed Warning ids grouped by kconfigs: recent_errors `-- x86_64-randconfig-161-20240704 |-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-recv_buf-double-freed `-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-send_buf-double-freed elapsed time: 734m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD SUCCESS b206e4b36a7f6d4d7806d653f1e71867dd56571d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: b206e4b36a7f6d4d7806d653f1e71867dd56571d !9757 net: openvswitch: fix overwriting ct original tuple for ICMPv6 Warning ids grouped by kconfigs: recent_errors `-- arm64-allmodconfig `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag elapsed time: 723m configs tested: 21 configs skipped: 124 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/2] Add a switch to enable hungtask check for io
by Li Lingfeng 05 Jul '24

05 Jul '24

Add a switch to enable hungtask check for io Li Lingfeng (1): block: disable BLK_IO_HUNG_TASK_CHECK by default Yu Kuai (1): block: add a switch to enable hungtask check for io arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + block/Kconfig | 9 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 ++++++++++++- block/blk-mq.c | 2 +- block/blk.h | 1 + 7 files changed, 26 insertions(+), 3 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-22.03-LTS-SP1] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 6fac6d0e975a ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index ad12ffcc5085..4760a481e444 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[PATCH OLK-5.10] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 48774b90b567 ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 61cc9a13a40a..fc9908d79f93 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS 451734a9a63432990e3124ae33b413c8bb221f5a
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 451734a9a63432990e3124ae33b413c8bb221f5a !9716 ax25: Fix reference count leak issues of ax25_dev Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 725m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 38510a24861d..ab708374d88e 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3572,9 +3572,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3592,6 +3595,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3725,9 +3730,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3745,6 +3753,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH OLK-5.10] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 01995d1b2437..eff0b359f1a3 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3579,9 +3579,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3599,6 +3602,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3732,9 +3737,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3752,6 +3760,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] i40e: Fix queues reservation for XDP
by Zeng Heng 04 Jul '24

04 Jul '24

From: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> stable inclusion from stable-v4.19.228 commit d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72DT CVE: CVE-2021-47619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream. When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Fixes: 41c445ff0f48 ("i40e: main driver core") Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski(a)intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski(a)intel.com> Tested-by: Kiran Bhandare <kiranx.bhandare(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 74cf22982f59..bfa5e286c489 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -193,6 +193,20 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile, return -EINVAL; } + /* Allocate last queue in the pile for FDIR VSI queue + * so it doesn't fragment the qp_pile + */ + if (pile == pf->qp_pile && pf->vsi[id]->type == I40E_VSI_FDIR) { + if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) { + dev_err(&pf->pdev->dev, + "Cannot allocate queue %d for I40E_VSI_FDIR\n", + pile->num_entries - 1); + return -ENOMEM; + } + pile->list[pile->num_entries - 1] = id | I40E_PILE_VALID_BIT; + return pile->num_entries - 1; + } + /* start the linear search with an imperfect hint */ i = pile->search_hint; while (i < pile->num_entries) { -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1